Alleen Cloudflare-IP’s toestaan op nginx, Apache en IIS

De proxy van Cloudflare verbergt het IP-adres van je server en voegt DDoS-bescherming toe, maar alleen voor verkeer dat echt via Cloudflare loopt. [1] Wie het echte IP-adres kent, kan rechtstreeks verbinding maken met de server en die bescherming volledig omzeilen. Deze gids laat zien hoe je op poort 80 en 443 alleen IP-adressen van Cloudflare toestaat, met UFW en nginx of Apache op Ubuntu 24.04 en met Windows Defender Firewall en IIS op Windows Server 2022 of 2025, en hoe je de lijst van Cloudflare actueel houdt.

Waarom iedereen met het IP-adres van je server Cloudflare kan omzeilen

Verzoeken die rechtstreeks naar het IP-adres van je server gaan, komen nooit langs Cloudflare, dus geldt geen van de beschermingsmaatregelen van Cloudflare voor die verzoeken. Een DNS-record met proxy verbergt het IP-adres van je origin-server, en Cloudflare vraagt je om zijn IP-adressen op de origin-server toe te staan, zodat zijn eigen verzoeken erdoor komen. [1] Het advies van Cloudflare op netwerkniveau gaat verder: blokkeer expliciet al het verkeer dat niet afkomstig is van Cloudflare of van partners die je vertrouwt. [1]

Beperk alleen TCP-poort 80 en 443 tot Cloudflare. SSH op Linux en Remote Desktop op Windows houd je beperkt tot je eigen IP-adres of een VPN: onze checklist voor SSH-hardening en de gids voor een privénetwerk met WireGuard behandelen beide.

Cloudflare beoordeelt een allowlist met IP-adressen als redelijk veilig, en Authenticated Origin Pulls en Cloudflare Tunnel als zeer veilig. [1] Deze gids bouwt de controles daarom in lagen op:

Een firewall op de server zelf houdt geen verkeersvloed tegen die groot genoeg is om de netwerkverbinding van de server te verzadigen. Bij de EU-pakketten van StealthRDP is DDoS-bescherming op netwerkniveau inbegrepen; bij de VS-pakketten niet. Meer daarover lees je in onze checklist voor DDoS-bescherming van een VPS.

Waar Cloudflare zijn IP-bereiken publiceert

De pagina IP Ranges op www.cloudflare.com/ips is bedoeld als de officiële lijst. Die pagina linkt naar kopieën in platte tekst op www.cloudflare.com/ips-v4 en www.cloudflare.com/ips-v6, en dezelfde lijst staat in de API van Cloudflare. [2]

De lijst verandert wel degelijk. Volgens de wijzigingsgeschiedenis is 199.27.128.0/21 in 2017 verwijderd, is 104.16.0.0/12 in 2021 vervangen door 104.16.0.0/13 en 104.24.0.0/14, en is 2405:b500::/32 in 2022 verwijderd en in 2023 weer toegevoegd. [2] Ontbreekt er een bereik, dan blokkeer je de verzoeken die Cloudflare vanuit dat bereik stuurt [1]; een lijst die je één keer plakt, raakt dus verouderd.

Alleen Cloudflare-IP’s toestaan in UFW

Om in UFW alleen IP-adressen van Cloudflare toe te staan, voeg je voor elk IP-bereik van Cloudflare regels toe voor poort 80 en 443 en verwijder je daarna de regels die deze poorten voor iedereen openzetten. UFW is de standaardfirewalltool van Ubuntu en staat na de installatie uit. UFW kan een poort openzetten voor één host of één netwerk, zoals in sudo ufw allow proto tcp from 192.168.0.2 to any port 22, en werkt met IPv4 en 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

Poorten die Docker publiceert, omzeilen UFW

Docker leidt het verkeer voor een gepubliceerde poort om in de nat-tabel, voordat het de INPUT-chain bereikt die UFW gebruikt. Voor die poort worden de regels van UFW dus genegeerd. [4] Docker raadt ook af om zijn regels te bewerken, en als je de iptables-afhandeling van Docker uitschakelt, werkt het netwerk van je containers waarschijnlijk niet meer. [4] Draai de webserver die het verkeer van Cloudflare ontvangt dus op de host zelf, of filter het verkeer in een firewall vóór de server.

nginx en Apache: IP-adressen van bezoekers herstellen en het kale IP-adres weigeren

Beide webservers kunnen het adres van Cloudflare vervangen door dat van de bezoeker, dat Cloudflare meestuurt in de header CF-Connecting-IP. [5] Dat heb je nodig, want met de firewall op zijn plaats komt elk verzoek van een adres van Cloudflare. Vertrouw de header alleen als hij uit de IP-bereiken van Cloudflare komt; anders kan hij volgens Cloudflare worden vervalst. [5]

nginx

De nginx-instructies van Cloudflare gebruiken de realip-module: een regel set_real_ip_from per IP-bereik van Cloudflare plus real_ip_header CF-Connecting-IP, waarbij je de bereiken actueel houdt. [5] Het updatescript schrijft dit bestand:

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;

Weiger vervolgens verzoeken voor namen die je niet host, zoals een verzoek aan het kale IP-adres: Cloudflare raadt aan alleen de waarden van de Host-header te accepteren die je verwacht. [1] In nginx doet een default server dat. deny all weigert elk verzoek dat bij die server aankomt [6], en ssl_reject_handshake on weigert TLS-handshakes in het bijbehorende serverblok; het voorbeeld van nginx zelf combineert die instructie met default_server, zodat handshakes voor alle overige namen mislukken. Deze instructie vereist nginx 1.19.4 of nieuwer. [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;
}

Verwijder default_server uit alle andere serverblokken op deze poorten, activeer het bestand en laad nginx opnieuw.

In nginx kun je de lijst van Cloudflare ook als allow-regels opnemen, afgesloten met deny all, omdat regels op volgorde worden gecontroleerd tot er één overeenkomt. [6] Doe dat alleen op een server die de IP-adressen van bezoekers niet herstelt, en log daar in plaats daarvan $http_cf_connecting_ip. [5] Een hersteld adres is dat van de bezoeker, dus een allowlist met alleen Cloudflare-adressen zou echte bezoekers weigeren, zoals de documentatie van Apache voor zijn eigen module uitlegt. [8]

Apache 2.4

De stappen van Cloudflare voor Apache gebruiken mod_remoteip: schakel de module in, stel RemoteIPHeader CF-Connecting-IP in, zet de IP-bereiken van Cloudflare als vertrouwde proxy’s in /etc/apache2/conf-available/remoteip.conf, activeer dat bestand en verander %h in %a in de LogFormat-regel van het formaat combined in /etc/apache2/apache2.conf. [5] RemoteIPTrustedProxyList leest de bereiken bij het opstarten uit een bestand, en dat past goed bij het 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

Twee details zijn belangrijk. Zonder vertrouwde proxy’s vertrouwt mod_remoteip de header van elke host, zodat iedereen zijn adres zou kunnen vervalsen. [8] En na de vervanging zien Require ip en het logveld %a het adres van de bezoeker, terwijl %{c}a en CONN_REMOTE_ADDR het Cloudflare-adres behouden waarvandaan de verbinding kwam. [8] Houd de IP-bereiken van Cloudflare dus in de lijst met vertrouwde proxy’s en in de firewall, en gebruik Require ip alleen voor regels over bezoekers, zoals een beheerpagina die alleen vanaf jouw IP-adres bereikbaar is.

IIS op Windows Server: poort 80 en 443 beperken tot Cloudflare

Op een Windows VPS met Windows Server 2022 of 2025 doet Windows Defender Firewall hetzelfde werk, aangestuurd vanuit PowerShell. New-NetFirewallRule accepteert voor -RemoteAddress IPv4- en IPv6-subnetten in CIDR-notatie, zodat één regel alle bereiken kan bevatten, en Set-NetFirewallRule wijzigt een bestaande regel. [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
}

Een allow-regel laat elk pakket door dat ermee overeenkomt [9], dus elke andere ingeschakelde regel die 80 of 443 vanaf elk adres toestaat, houdt die poorten voor iedereen open. Toon die regels, controleer ze één voor één en schakel de regels uit die niet van jou zijn:

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

Om voor IIS 8.5 tot en met 10 het echte IP-adres van de bezoeker te loggen, voeg je volgens de stappen van Cloudflare CF-Connecting-IP toe als aangepast veld: open in IIS Manager Logging voor de site, selecteer het W3C-formaat, kies Select Fields en voeg de header toe. [5] Dat verandert alleen het log; je applicatie ziet nog steeds het adres van Cloudflare. [5]

Authenticated Origin Pulls: de sterkste controle op je origin-server

Authenticated Origin Pulls (AOP) voegt mutual TLS (wederzijdse TLS-authenticatie) toe: Cloudflare biedt een clientcertificaat aan wanneer het verbinding maakt met je origin-server, en de webserver controleert dat certificaat. Daarvoor moet de SSL/TLS-versleutelingsmodus op Full of hoger staan. [10] De globale configuratie gebruikt een certificaat van Cloudflare dat alle Cloudflare-accounts delen, dus die toont alleen aan dat een verzoek van het netwerk van Cloudflare kwam. Wil je een controle die aan jouw account gekoppeld is, upload dan je eigen certificaat met AOP op zoneniveau of per hostnaam. [10]

Download het origin-pull-certificaat van Cloudflare (.PEM) via de installatiehandleiding en kopieer het naar de server; dit is niet het certificaat van Cloudflare Origin CA. [10] Verwijs de webserver naar dat certificaat, maar dwing nog niets af; in nginx betekent dat ssl_verify_client optional, dat om een clientcertificaat vraagt en het controleert als er een wordt meegestuurd. [7] Zet AOP daarna aan in Cloudflare: pagina Origin Server, tabblad Authenticated Origin Pulls, onderdeel Global. [10]

Werkt de site nog, dwing de controle dan af: 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: helemaal geen inkomende webpoorten

Cloudflare Tunnel sluit de webpoorten in plaats van ze te filteren. De daemon cloudflared op je server maakt alleen uitgaande verbindingen met Cloudflare, dus de site heeft geen publiek routeerbaar IP-adres nodig. [1] Zodra de tunnel actief is, kunnen poort 80 en 443 dicht blijven. Cloudflare beoordeelt Tunnel als zeer veilig en biedt het aan alle klanten aan; daar staat tegenover dat je een extra dienst moet draaien. [1]

Hoe origin-IP’s uitlekken en hoe je de afscherming test

Origin-IP’s lekken meestal uit via DNS-records zonder proxy, mail op dezelfde server of oude DNS-geschiedenis, zoals de gids van Cloudflare over het beschermen van je origin-server uitlegt. [1]

• DNS-records zonder proxy (DNS only) die het origin-IP bevatten, ook SPF- en TXT-records.
• Mail op dezelfde server: mail aan een niet-bestaand adres komt terug als bounce en toont het IP-adres van de mailserver.
• DNS-geschiedenis: oude records worden bewaard en tonen het IP-adres dat je vóór Cloudflare gebruikte.

Cloudflare raadt aan het origin-IP te wisselen zodra je site via Cloudflare loopt. [1] Doe dat na de afscherming, zodat het nieuwe adres nooit openbaar is geweest. Elke server van StealthRDP, Linux VPS of Windows, heeft een dedicated IPv4-adres, en een IP-wijziging kost € 5 per keer, aan te vragen via support.

Test daarna vanaf je eigen computer; die heeft door de firewall geen toegang meer tot poort 80 en 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/

Een time-out is precies wat je wilt. Een 403-pagina, of welke TLS- of certificaatfout ook, betekent dat het verzoek de webserver heeft bereikt; de firewall staat dus nog open.

Zodra AOP wordt afgedwongen, hoort een verzoek dat niet via Cloudflare loopt, ook op de certificaatcontrole te stranden. [10] Vanaf je computer houdt de firewall zo’n verzoek tegen voordat het zo ver komt, dus voer deze test op de server zelf uit:

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

Als het goed is, antwoordt nginx met foutcode 400 omdat er geen clientcertificaat is meegestuurd, en weigert Apache de TLS-handshake. Zien bezoekers daarna foutpagina’s van Cloudflare, controleer dan of alle bereiken zijn toegevoegd; onze gids over 502 Bad Gateway behandelt andere origin-fouten achter Cloudflare.

Veelgestelde vragen

Waar vind ik de IP-bereiken van Cloudflare?

Cloudflare publiceert ze op www.cloudflare.com/ips, met lijsten in platte tekst op www.cloudflare.com/ips-v4 en www.cloudflare.com/ips-v6 en dezelfde gegevens in de API. De lijst verandert af en toe, dus werk je eigen kopie automatisch bij. [2]

Kan iemand Cloudflare omzeilen met het IP-adres van mijn server?

Ja, als de server webverkeer van iedereen accepteert. DNS-records zonder proxy, teruggestuurde mails (bounces) en oude DNS-records kunnen het IP-adres verraden, dus Cloudflare raadt aan verkeer te blokkeren dat niet van zijn adressen komt. [1]

Hoe zie ik het echte IP-adres van een bezoeker achter Cloudflare?

Cloudflare stuurt het mee in de header CF-Connecting-IP. De realip-module van nginx en mod_remoteip van Apache kunnen die header gebruiken, zolang je hem alleen vertrouwt als hij uit de IP-bereiken van Cloudflare komt. [5]

Blokkeert UFW Docker-poorten?

Niet voor poorten die een container publiceert. Docker leidt dat verkeer in de nat-tabel om voordat het de chains bereikt die UFW gebruikt, dus voor die poorten worden de regels van UFW genegeerd. [4]

Heb ik open poorten nodig voor Cloudflare Tunnel?

Er zijn geen inkomende webpoorten nodig. De daemon cloudflared maakt alleen uitgaande verbindingen met Cloudflare, dus de server heeft voor de site geen publiek routeerbaar IP-adres nodig. [1]