Consentire solo gli IP di Cloudflare su nginx, Apache e IIS

Il proxy di Cloudflare nasconde l’indirizzo IP del tuo server e aggiunge la protezione DDoS, ma solo per il traffico che passa davvero da Cloudflare. [1] Chiunque scopra l’IP reale può collegarsi direttamente al server e aggirare tutte queste protezioni. Questa guida spiega come consentire solo agli IP di Cloudflare l’accesso alle porte 80 e 443, con UFW e nginx o Apache su Ubuntu 24.04 e con Windows Defender Firewall e IIS su Windows Server 2022 o 2025, e come tenere aggiornato l’elenco di Cloudflare.

Perché chi conosce l’IP del tuo server può aggirare Cloudflare

Le richieste inviate direttamente all’IP del tuo server non passano mai da Cloudflare, quindi nessuna delle sue protezioni si applica. Un record DNS con proxy attivo nasconde l’IP del server di origine, e Cloudflare chiede di autorizzare i suoi indirizzi IP su quel server, così che le sue richieste possano passare. [1] Il suo consiglio a livello di rete va oltre: bloccare esplicitamente tutto il traffico che non arriva da Cloudflare o da partner di cui ti fidi. [1]

Limita a Cloudflare solo le porte TCP 80 e 443. Tieni SSH su Linux e Desktop remoto su Windows accessibili solo dal tuo indirizzo IP o tramite una VPN: la nostra checklist di hardening SSH e la guida a una rete privata WireGuard coprono entrambi i casi.

Cloudflare giudica moderatamente sicuro un elenco di IP consentiti (allowlist), e molto sicuri Authenticated Origin Pulls e Cloudflare Tunnel. [1] Per questo la guida combina più livelli di controllo:

Un firewall sull’host non può fermare un’ondata di traffico così grande da saturare la connessione del server. I piani UE di StealthRDP includono la protezione DDoS a livello di rete; i piani USA no. La nostra checklist di protezione DDoS per VPS tratta questo aspetto.

Dove Cloudflare pubblica i suoi intervalli IP

La pagina IP Ranges di Cloudflare, all’indirizzo www.cloudflare.com/ips, è pensata per essere l’elenco ufficiale. Rimanda a copie in testo semplice su www.cloudflare.com/ips-v4 e www.cloudflare.com/ips-v6, e lo stesso elenco è disponibile nell’API di Cloudflare. [2]

E l’elenco cambia davvero. La cronologia degli aggiornamenti mostra che 199.27.128.0/21 è stato rimosso nel 2017, che nel 2021 104.16.0.0/12 è stato sostituito da 104.16.0.0/13 e 104.24.0.0/14, e che 2405:b500::/32 è stato rimosso nel 2022 e aggiunto di nuovo nel 2023. [2] Se nel tuo elenco manca un intervallo, le richieste di Cloudflare che ne provengono vengono bloccate [1], quindi un elenco incollato una volta per tutte finisce per diventare obsoleto.

Come consentire solo gli IP di Cloudflare con UFW

Per consentire solo gli IP di Cloudflare con UFW, aggiungi per ogni intervallo di Cloudflare le regole che aprono le porte 80 e 443, poi elimina quelle che aprono le stesse porte a tutti. UFW è lo strumento firewall predefinito di Ubuntu e inizialmente è disattivato; può aprire una porta a un singolo host o a una rete, come in sudo ufw allow proto tcp from 192.168.0.2 to any port 22, e gestisce sia IPv4 sia 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

Le porte pubblicate da Docker scavalcano UFW

Docker devia il traffico di una porta pubblicata nella tabella nat, prima che raggiunga la catena INPUT usata da UFW, quindi per quella porta le regole di UFW vengono ignorate. [4] Docker sconsiglia anche di modificare le sue regole, e se disattivi la gestione di iptables da parte di Docker è probabile che la rete dei container smetta di funzionare. [4] Fai girare direttamente sull’host il server web che riceve il traffico di Cloudflare, oppure filtra il traffico con un firewall posto davanti al server.

nginx e Apache: ripristina l’IP dei visitatori e rifiuta le richieste dirette all’IP

Entrambi i server web possono sostituire l’indirizzo di Cloudflare con quello del visitatore, che Cloudflare invia nell’header CF-Connecting-IP. [5] Ti serve perché, con il firewall attivo, ogni richiesta arriva da un indirizzo di Cloudflare. Fidati dell’header solo se arriva dagli intervalli di Cloudflare: altrimenti, avverte Cloudflare, potrebbe essere falsificato. [5]

nginx

La configurazione di nginx indicata da Cloudflare usa il modulo realip: una riga set_real_ip_from per ogni intervallo di Cloudflare più real_ip_header CF-Connecting-IP, con gli intervalli sempre aggiornati. [5] Lo script di aggiornamento scrive questo file:

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;

Poi rifiuta le richieste per nomi di dominio che non ospiti, come una richiesta diretta all’IP: Cloudflare consiglia di accettare solo i valori dell’header Host che ti aspetti. [1] In nginx se ne occupa un server predefinito. deny all respinge ogni richiesta che lo raggiunge [6], e ssl_reject_handshake on rifiuta gli handshake TLS nel suo blocco server; l’esempio della documentazione di nginx lo abbina a default_server, così gli handshake per qualsiasi altro nome falliscono. La direttiva richiede nginx 1.19.4 o versioni successive. [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;
}

Togli default_server da qualsiasi altro blocco server su queste porte, abilita il file e ricarica nginx.

In nginx potresti anche inserire l’elenco di Cloudflare come righe allow chiuse da deny all, perché le regole vengono controllate in ordine finché una non corrisponde. [6] Usa questo metodo solo su un server che non ripristina l’IP dei visitatori, e in quel caso registra nei log $http_cf_connecting_ip. [5] Un indirizzo ripristinato è quello del visitatore, quindi un elenco di indirizzi consentiti limitato a Cloudflare rifiuterebbe i visitatori reali, come spiega chiaramente la documentazione di Apache a proposito del proprio modulo. [8]

Apache 2.4

La procedura di Cloudflare per Apache usa mod_remoteip: abilita il modulo, imposta RemoteIPHeader CF-Connecting-IP, elenca gli intervalli di Cloudflare come proxy attendibili in /etc/apache2/conf-available/remoteip.conf, abilita quel file e sostituisci %h con %a nel LogFormat combined di /etc/apache2/apache2.conf. [5] RemoteIPTrustedProxyList legge gli intervalli da un file all’avvio, cosa comoda per lo 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

Due dettagli sono importanti. Senza proxy attendibili, mod_remoteip si fida dell’header proveniente da qualsiasi host, quindi chiunque potrebbe falsificare il proprio indirizzo. [8] Inoltre, dopo la sostituzione, Require ip e il campo di log %a vedono l’indirizzo del visitatore, mentre %{c}a e CONN_REMOTE_ADDR conservano l’indirizzo di Cloudflare che ha aperto la connessione. [8] Tieni quindi gli intervalli di Cloudflare nell’elenco dei proxy attendibili e nel firewall, e usa Require ip solo per le regole che riguardano i visitatori, come una pagina di amministrazione limitata al tuo IP.

IIS su Windows Server: limita le porte 80 e 443 a Cloudflare

Su un VPS Windows con Windows Server 2022 o 2025, Windows Defender Firewall fa lo stesso lavoro da PowerShell. New-NetFirewallRule accetta per -RemoteAddress subnet IPv4 e IPv6 in notazione CIDR, quindi una sola regola contiene tutti gli intervalli, e Set-NetFirewallRule modifica una regola esistente. [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
}

Una regola Allow lascia passare ogni pacchetto che le corrisponde [9], quindi qualsiasi altra regola attiva che apre le porte 80 o 443 a qualunque indirizzo le lascia aperte a tutti. Elenca quelle regole, controllale una per una e disattiva quelle che non hai creato tu:

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

Per le versioni di IIS dalla 8.5 alla 10, la procedura di Cloudflare registra nei log l’IP reale del visitatore aggiungendo CF-Connecting-IP come campo personalizzato: in IIS Manager apri Logging per il sito, seleziona il formato W3C, scegli Select Fields e aggiungi l’header. [5] Questo cambia solo il log: la tua applicazione continua a vedere l’indirizzo di Cloudflare. [5]

Authenticated Origin Pulls: il controllo più forte sull’origine

Authenticated Origin Pulls (AOP) aggiunge l’autenticazione TLS reciproca (mTLS): quando si collega al tuo server di origine, Cloudflare presenta un certificato client e il server web lo verifica. Richiede la modalità di crittografia SSL/TLS Full o superiore. [10] La configurazione globale usa un certificato di Cloudflare condiviso da tutti gli account Cloudflare, quindi dimostra solo che una richiesta arriva dalla rete di Cloudflare; per un controllo legato al tuo account, carica un tuo certificato con l’AOP a livello di zona o per singolo hostname. [10]

Scarica dalla guida di configurazione il certificato origin pull di Cloudflare (.PEM) e copialo sul server; non è il certificato Cloudflare Origin CA. [10] Fai puntare il server web al certificato senza ancora imporre il controllo; in nginx questo significa ssl_verify_client optional, che chiede un certificato client e lo verifica se viene inviato. [7] Poi attiva l’AOP in Cloudflare: pagina Origin Server, scheda Authenticated Origin Pulls, sezione Global. [10]

Se il sito funziona ancora, rendi obbligatorio il controllo: ssl_verify_client on in nginx, SSLVerifyClient require in 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: nessuna porta web in entrata

Cloudflare Tunnel chiude le porte web invece di filtrarle. Il demone cloudflared sul tuo server apre solo connessioni in uscita verso Cloudflare, quindi il sito non ha bisogno di un indirizzo IP pubblicamente instradabile. [1] Con il tunnel attivo, le porte 80 e 443 possono restare chiuse. Cloudflare considera Tunnel molto sicuro e lo offre a tutti i clienti; il rovescio della medaglia è un servizio in più da gestire. [1]

Come trapela l’IP di origine e come verificare il blocco

Di solito l’IP di origine trapela attraverso record impostati su DNS only, la posta sullo stesso server o la vecchia cronologia DNS, come spiega la guida di Cloudflare sulla protezione dell’origine. [1]

• Record impostati su DNS only che contengono l’IP di origine, compresi i record SPF e TXT.
• Posta sullo stesso server: un messaggio inviato a un indirizzo inesistente torna indietro come mancato recapito e mostra l’IP del server di posta.
• Cronologia DNS: i vecchi record restano archiviati e mostrano l’IP che usavi prima di Cloudflare.

Cloudflare consiglia di cambiare l’IP di origine una volta completato il passaggio a Cloudflare. [1] Fallo dopo aver attivato il blocco, così il nuovo indirizzo non verrà mai esposto pubblicamente. Ogni server StealthRDP, VPS Linux o Windows, ha un indirizzo IPv4 dedicato, e ogni cambio di IP costa 5 € e si richiede all’assistenza.

Poi fai una prova dal tuo computer, a cui il firewall blocca l’accesso alle porte 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/

Quello che vuoi ottenere è un timeout. Una pagina 403, o qualsiasi errore TLS o di certificato, significa che la richiesta ha raggiunto il server web, quindi il firewall è ancora aperto.

Una volta reso obbligatorio l’AOP, una richiesta che non passa da Cloudflare non dovrebbe superare nemmeno il controllo del certificato. [10] Dal tuo computer, il firewall blocca una richiesta del genere prima che arrivi fin lì, quindi fai questa prova sul server stesso:

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

nginx dovrebbe rispondere con un errore 400 perché non è stato inviato alcun certificato client, mentre Apache dovrebbe rifiutare l’handshake TLS. Se dopo questi passaggi i visitatori vedono pagine di errore di Cloudflare, controlla che tutti gli intervalli siano presenti; la nostra guida all’errore 502 Bad Gateway tratta gli altri errori dell’origine dietro Cloudflare.

Domande frequenti

Dove trovo gli intervalli IP di Cloudflare?

Cloudflare li pubblica su www.cloudflare.com/ips, con elenchi in testo semplice su www.cloudflare.com/ips-v4 e www.cloudflare.com/ips-v6 e gli stessi dati nella sua API. L’elenco cambia di tanto in tanto, quindi aggiorna la tua copia in automatico. [2]

Qualcuno può aggirare Cloudflare con l’IP del mio server?

Sì, se il server accetta traffico web da chiunque. I record impostati su DNS only, i messaggi di mancato recapito e i vecchi record DNS possono rivelare l’IP, quindi Cloudflare consiglia di bloccare il traffico che non arriva dai suoi indirizzi. [1]

Come vedo l’IP reale dei visitatori dietro Cloudflare?

Cloudflare lo invia nell’header CF-Connecting-IP. Il modulo realip di nginx e mod_remoteip di Apache possono usarlo, a patto che ti fidi dell’header solo quando arriva dagli intervalli di Cloudflare. [5]

UFW blocca le porte di Docker?

No, non blocca quelle pubblicate da un container. Docker devia quel traffico nella tabella nat prima che raggiunga le catene usate da UFW, quindi per quelle porte le regole di UFW vengono ignorate. [4]

Servono porte aperte per Cloudflare Tunnel?

Non serve nessuna porta web in entrata. Il demone cloudflared apre solo connessioni in uscita verso Cloudflare, quindi per il sito il server non ha bisogno di un indirizzo IP pubblicamente instradabile. [1]