Autoriser uniquement les IP Cloudflare sur nginx, Apache et IIS

Le proxy de Cloudflare masque l’adresse IP de votre serveur et ajoute une protection DDoS, mais seulement pour le trafic qui passe réellement par Cloudflare. [1] Quiconque découvre l’IP réelle peut se connecter directement au serveur et contourner toutes ces protections. Ce guide explique comment autoriser uniquement les IP Cloudflare sur les ports 80 et 443, avec UFW et nginx ou Apache sous Ubuntu 24.04, et avec Windows Defender Firewall et IIS sous Windows Server 2022 ou 2025, puis comment tenir à jour la liste de Cloudflare.

Pourquoi quiconque connaît l’IP de votre serveur peut contourner Cloudflare

Les requêtes envoyées directement à l’IP de votre serveur ne passent jamais par Cloudflare : aucune de ses protections ne s’y applique donc. Un enregistrement DNS proxifié masque l’IP d’origine, et Cloudflare vous demande d’autoriser ses adresses IP sur le serveur d’origine pour que ses propres requêtes passent. [1] Ses recommandations au niveau du réseau vont plus loin : bloquer explicitement tout le trafic qui ne provient ni de Cloudflare ni de partenaires de confiance. [1]

Ne réservez à Cloudflare que les ports TCP 80 et 443. Limitez SSH sous Linux et le Bureau à distance sous Windows à votre propre adresse IP ou à un VPN : notre check-list de durcissement SSH et le guide du réseau privé WireGuard couvrent ces deux options.

Cloudflare considère une liste d’adresses IP autorisées comme moyennement sûre, et Authenticated Origin Pulls ainsi que Cloudflare Tunnel comme très sûrs. [1] Ce guide cumule donc plusieurs contrôles :

Un pare-feu installé sur le serveur ne peut pas arrêter un afflux de trafic assez massif pour saturer sa connexion réseau. Les offres UE de StealthRDP incluent une protection DDoS au niveau du réseau ; les offres USA, non. Notre check-list de protection DDoS pour VPS traite cet aspect.

Où Cloudflare publie ses plages d’IP

La page IP Ranges de Cloudflare, à l’adresse www.cloudflare.com/ips, se veut la liste de référence. Elle renvoie vers des copies en texte brut sur www.cloudflare.com/ips-v4 et www.cloudflare.com/ips-v6, et la même liste figure dans l’API Cloudflare. [2]

Cette liste change bel et bien. Son historique de mises à jour montre que la plage 199.27.128.0/21 a été retirée en 2017, que 104.16.0.0/12 a été remplacée par 104.16.0.0/13 et 104.24.0.0/14 en 2021, et que 2405:b500::/32 a été retirée en 2022 puis rajoutée en 2023. [2] S’il vous manque une plage, les requêtes que Cloudflare envoie depuis cette plage sont bloquées [1] : une liste collée une fois pour toutes finira donc par être périmée.

Autoriser uniquement les IP Cloudflare dans UFW

Pour autoriser uniquement les IP Cloudflare dans UFW, ajoutez des règles qui ouvrent les ports 80 et 443 à chaque plage Cloudflare, puis supprimez les règles qui ouvrent ces ports à tout le monde. UFW, l’outil de pare-feu par défaut d’Ubuntu, est désactivé au départ ; il peut ouvrir un port à un seul hôte ou à un seul réseau, comme avec sudo ufw allow proto tcp from 192.168.0.2 to any port 22, et il gère IPv4 et 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

Les ports publiés par Docker échappent à UFW

Docker détourne le trafic d’un port publié dans la table nat, avant qu’il n’atteigne la chaîne INPUT qu’utilise UFW : les règles d’UFW sont donc ignorées pour ce port. [4] Docker déconseille aussi de modifier ses règles, et désactiver sa gestion d’iptables risque fort de casser le réseau des conteneurs. [4] Gardez sur l’hôte le serveur web qui reçoit le trafic de Cloudflare, ou filtrez avec un pare-feu placé devant le serveur.

nginx et Apache : restaurer l’IP des visiteurs et refuser l’accès par IP

Les deux serveurs web peuvent remplacer l’adresse de Cloudflare par celle du visiteur, que Cloudflare transmet dans l’en-tête CF-Connecting-IP. [5] C’est nécessaire car, une fois le pare-feu en place, toutes les requêtes proviennent d’une adresse Cloudflare. Ne faites confiance à cet en-tête que s’il provient des plages Cloudflare ; sinon, prévient Cloudflare, il pourrait être falsifié. [5]

nginx

La configuration nginx recommandée par Cloudflare utilise le module realip : une ligne set_real_ip_from par plage Cloudflare, plus real_ip_header CF-Connecting-IP, avec des plages tenues à jour. [5] Le script de mise à jour écrit ce fichier :

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;

Refusez ensuite les requêtes pour des noms que vous n’hébergez pas, comme une requête adressée directement à l’IP : Cloudflare conseille de n’accepter que les valeurs d’en-tête Host attendues. [1] Dans nginx, c’est le rôle d’un serveur par défaut. deny all refuse toutes les requêtes qui lui parviennent [6], et ssl_reject_handshake on rejette les négociations TLS dans son bloc server ; l’exemple de la documentation nginx l’associe à default_server, si bien que les négociations pour tout autre nom échouent. Cette directive nécessite nginx 1.19.4 ou une version ultérieure. [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;
}

Retirez default_server de tous les autres blocs server sur ces ports, activez le fichier et rechargez nginx.

On pourrait aussi placer la liste de Cloudflare dans nginx sous forme de lignes allow suivies d’un deny all final, puisque les règles sont évaluées dans l’ordre jusqu’à ce que l’une d’elles corresponde. [6] Réservez cette méthode à un serveur qui ne restaure pas l’IP des visiteurs, et enregistrez plutôt $http_cf_connecting_ip dans ses journaux. [5] Une adresse restaurée est celle du visiteur : une liste d’autorisation limitée à Cloudflare refuserait donc les vrais visiteurs, comme la documentation d’Apache le précise pour son propre module. [8]

Apache 2.4

La procédure de Cloudflare pour Apache utilise mod_remoteip : activez le module, définissez RemoteIPHeader CF-Connecting-IP, déclarez les plages Cloudflare comme proxys de confiance dans /etc/apache2/conf-available/remoteip.conf, activez ce fichier et remplacez %h par %a dans la ligne LogFormat du format combined, dans /etc/apache2/apache2.conf. [5] RemoteIPTrustedProxyList lit les plages dans un fichier au démarrage, ce qui convient bien au 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

Deux points importants. Sans proxy de confiance déclaré, mod_remoteip accepte l’en-tête quel que soit l’hôte qui l’envoie : n’importe qui pourrait donc falsifier son adresse. [8] Et après la substitution, Require ip et le champ de journal %a voient l’adresse du visiteur, tandis que %{c}a et CONN_REMOTE_ADDR conservent l’adresse Cloudflare qui s’est connectée. [8] Gardez donc les plages Cloudflare dans la liste de confiance et dans le pare-feu, et n’utilisez Require ip que pour des règles qui concernent les visiteurs, comme une page d’administration limitée à votre IP.

IIS sous Windows Server : réserver les ports 80 et 443 à Cloudflare

Sur un VPS Windows sous Windows Server 2022 ou 2025, Windows Defender Firewall fait le même travail depuis PowerShell. New-NetFirewallRule accepte pour -RemoteAddress des sous-réseaux IPv4 et IPv6 en notation CIDR : une seule règle peut donc contenir toutes les plages, et Set-NetFirewallRule modifie une règle existante. [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
}

Une règle d’autorisation laisse passer tous les paquets qui lui correspondent [9] : toute autre règle active qui autorise le 80 ou le 443 depuis n’importe où les laisse donc ouverts à tout le monde. Listez ces règles, examinez-les une par une et désactivez celles qui ne sont pas les vôtres :

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

Pour IIS 8.5 à 10, la procédure de Cloudflare enregistre l’IP réelle du visiteur dans les journaux en ajoutant CF-Connecting-IP comme champ personnalisé : dans IIS Manager, ouvrez Logging pour le site, sélectionnez le format W3C, choisissez Select Fields et ajoutez l’en-tête. [5] Seul le journal change : votre application voit toujours l’adresse de Cloudflare. [5]

Authenticated Origin Pulls : la vérification d’origine la plus solide

Authenticated Origin Pulls (AOP) ajoute une authentification TLS mutuelle : Cloudflare présente un certificat client lorsqu’il se connecte à votre serveur d’origine, et le serveur web le vérifie. Cette fonction exige le mode de chiffrement SSL/TLS Full ou un mode supérieur. [10] La configuration globale utilise un certificat Cloudflare partagé par tous les comptes Cloudflare, si bien qu’elle prouve seulement qu’une requête vient du réseau de Cloudflare ; pour une vérification liée à votre compte, importez votre propre certificat avec l’AOP au niveau de la zone ou par nom d’hôte. [10]

Téléchargez le certificat origin pull de Cloudflare (.PEM) depuis le guide de configuration et copiez-le sur le serveur ; il ne s’agit pas du certificat Cloudflare Origin CA. [10] Configurez le serveur web pour qu’il l’utilise, sans rien imposer pour l’instant ; dans nginx, cela correspond à ssl_verify_client optional, qui demande un certificat client et le vérifie s’il est envoyé. [7] Activez ensuite l’AOP dans Cloudflare : page Origin Server, onglet Authenticated Origin Pulls, section Global. [10]

Si le site fonctionne toujours, rendez-la obligatoire : ssl_verify_client on dans nginx, SSLVerifyClient require dans 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 : aucun port web entrant

Cloudflare Tunnel ferme les ports web au lieu de les filtrer. Le démon cloudflared installé sur votre serveur n’établit que des connexions sortantes vers Cloudflare : le site n’a donc besoin d’aucune adresse IP routable publiquement. [1] Une fois le tunnel actif, les ports 80 et 443 peuvent rester fermés. Cloudflare juge Tunnel très sûr et le propose à tous ses clients ; la contrepartie, c’est un service de plus à faire tourner. [1]

Fuites de l’IP d’origine et test du verrouillage

L’IP d’origine est le plus souvent révélée par des enregistrements DNS only (non proxifiés), par la messagerie hébergée sur le même serveur ou par l’historique DNS, comme l’explique le guide de Cloudflare sur la protection du serveur d’origine. [1]

• Les enregistrements DNS only qui contiennent l’IP d’origine, y compris les enregistrements SPF et TXT.
• La messagerie sur le même serveur : un e-mail envoyé à une adresse inexistante revient avec un message de non-remise qui révèle l’IP du serveur de messagerie.
• L’historique DNS : les anciens enregistrements sont conservés et montrent l’IP que vous utilisiez avant Cloudflare.

Cloudflare conseille de changer l’IP d’origine une fois votre site intégré à Cloudflare. [1] Faites-le après le verrouillage, pour que la nouvelle adresse n’ait jamais été publique. Chaque serveur StealthRDP, VPS Linux ou Windows, dispose d’une adresse IPv4 dédiée, et chaque changement d’IP coûte 5 € et se demande auprès du support.

Testez ensuite depuis votre propre ordinateur, que le pare-feu empêche d’atteindre les ports 80 et 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/

Le résultat attendu est un dépassement de délai (timeout). Une page 403, ou toute erreur TLS ou de certificat, signifie que la requête a atteint le serveur web : le pare-feu est donc encore ouvert.

Une fois l’AOP rendu obligatoire, une requête qui ne passe pas par Cloudflare doit, elle aussi, échouer à la vérification du certificat. [10] Depuis votre ordinateur, le pare-feu bloque une telle requête avant qu’elle n’arrive jusque-là ; faites donc ce test sur le serveur lui-même :

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

Le serveur nginx doit répondre par une erreur 400, puisqu’aucun certificat client n’a été envoyé, et Apache doit refuser la négociation TLS. Si des visiteurs voient ensuite des pages d’erreur Cloudflare, vérifiez que toutes les plages sont bien en place ; notre guide sur l’erreur 502 Bad Gateway traite les autres erreurs d’origine derrière Cloudflare.

Questions fréquentes

Où trouver les plages d’IP de Cloudflare ?

Cloudflare les publie sur www.cloudflare.com/ips, avec des listes en texte brut sur www.cloudflare.com/ips-v4 et www.cloudflare.com/ips-v6, et les mêmes données dans son API. La liste change de temps en temps : mettez donc votre copie à jour automatiquement. [2]

Quelqu’un peut-il contourner Cloudflare avec l’IP de mon serveur ?

Oui, si le serveur accepte le trafic web de n’importe qui. Les enregistrements DNS only, les messages de non-remise et les anciens enregistrements DNS peuvent révéler l’IP : Cloudflare conseille donc de bloquer le trafic qui ne provient pas de ses adresses. [1]

Comment voir l’IP réelle des visiteurs derrière Cloudflare ?

Cloudflare la transmet dans l’en-tête CF-Connecting-IP. Le module realip de nginx et le module mod_remoteip d’Apache peuvent l’exploiter, à condition que vous ne fassiez confiance à cet en-tête que s’il provient des plages Cloudflare. [5]

UFW bloque-t-il les ports Docker ?

Pas ceux qu’un conteneur publie. Docker détourne ce trafic dans la table nat avant qu’il n’atteigne les chaînes qu’utilise UFW : les règles d’UFW sont donc ignorées pour ces ports. [4]

Faut-il des ports ouverts pour Cloudflare Tunnel ?

Aucun port web entrant n’est nécessaire. Le démon cloudflared n’établit que des connexions sortantes vers Cloudflare : le serveur n’a donc besoin d’aucune adresse IP routable publiquement pour le site. [1]