Cloudflare Origin-IP-Whitelist: 3 Methoden zum Blockieren von Nicht-CF-Traffic und Schutz des Origin-Servers

Ein Origin-IP-Leak macht den Cloudflare-Schutz wirkungslos. Kennt ein Angreifer die Origin-IP, umgeht er Cloudflare und greift den Server direkt an – DDoS trifft den Origin, Ports werden gescannt, Schwachstellen ausgenutzt. Leak-Pfade: SSL-Zertifikatsabfrage, historische DNS-Einträge, Subdomains oder Mail ohne CDN.

Echten Schutz bietet Cloudflare-Proxy allein nicht. Am Server brauchen Sie eine Firewall, die nur Cloudflare-Origin-IPs zulässt und allen anderen Traffic blockiert. Dieser Artikel erklärt drei Methoden: BT-Panel (am einfachsten), reines Nginx (flexibler), Origin-Zertifikat (am sichersten). Vollständige IP-Liste, Schritte, Tests und Troubleshooting inklusive.

Warum Nicht-CF-Traffic blockieren? Das echte Risiko eines Origin-IP-Leaks

Zuerst: Wie gelangt die Origin-IP nach außen? Viele denken, DNS auf Cloudflare reiche – Angreifer haben mehrere Wege.

Häufige Leak-Pfade

Typisch ist die SSL-Zertifikatsabfrage. Auf myssl.com und ähnlichen Seiten kann die echte IP sichtbar werden. Warum? Mit Cloudflare-CDN und SSL zeigt die Zertifikatsprüfung oft die Origin-IP. Wer das zum ersten Mal sieht, ist meist überrascht – praktisch eine Einladung zum Angriff.

Dazu kommen historische DNS-Einträge. Viele Abfragedienste cachen Ergebnisse, manche speichern dauerhaft. Auch nach Umstellung auf Cloudflare finden sich alte Origin-IPs in der Historie.

Subdomains oder Mail-Systeme sind eine weitere Falle. Die Hauptdomain läuft über CDN, Subdomain oder Mail nicht. Ein Ping auf mail.example.com oder ein Blick in den Mail-Header – und die Origin-IP ist bekannt. Ein Bekannter aus dem Ops-Bereich hatte die Hauptsite gut abgesichert, bis die Mail-Server-IP gefunden und der Server lahmgelegt wurde.

Schaden nach dem Leak

Ist die Origin-IP bekannt, greifen Angreifer Cloudflare direkt an. DDoS trifft den Origin, kleine Leitungen sind schnell überlastet. Ports werden gescannt, gezielte Angriffe folgen.

Cloudflare-Schutz wirkt dann nicht mehr. Im CF-Dashboard sieht alles ruhig aus – der Origin kann längst unter Last stehen. Auf V2EX klagte jemand: „Server unter Angriff, CDN aktiv, Origin-IP trotzdem schnell bekannt – wo ist das Leck?“ – oft fehlt die Whitelist.

Wo finde ich die Cloudflare-Origin-IP-Liste? Aktuelle IP-Ranges

Für die Whitelist brauchen Sie die offiziellen Cloudflare-Origin-IPs. Cloudflare pflegt dafür eigene Seiten.

Offizielle IP-Listen

Cloudflare bietet drei Adressen:

• Vollständige Liste: https://www.cloudflare.com/ips/
• IPv4-Liste: https://www.cloudflare.com/ips-v4
• IPv6-Liste: https://www.cloudflare.com/ips-v6

Diese Seiten am besten bookmarken – für Updates und Wartung.

Aktuelle Cloudflare-IPv4-Ranges

Stand heute umfasst die IPv4-Origin-Liste 15 CIDR-Blöcke (CIDR = kompakte Notation für zusammenhängende IP-Bereiche):

173.245.48.0/20
103.21.244.0/22
103.22.200.0/22
103.31.4.0/22
141.101.64.0/18
108.162.192.0/18
190.93.240.0/20
188.114.96.0/20
197.234.240.0/22
198.41.128.0/17
162.158.0.0/15
104.16.0.0/13
104.24.0.0/14
172.64.0.0/13
131.0.72.0/22

Diese 15 Blöcke decken etwa 1,78 Millionen IP-Adressen ab.

IPv6-Ranges

Ist IPv6 auf dem Server aktiv, gehören auch diese Blöcke in die Whitelist:

2400:cb00::/32
2606:4700::/32
2803:f800::/32
2405:b500::/32
2405:8100::/32
2a06:98c0::/29
2c0f:f248::/32

Wichtig: Die Cloudflare-IP-Liste wird unregelmäßig aktualisiert. Alle ein bis zwei Monate die offizielle Seite prüfen. Sonst blockieren Sie neue CF-IPs und verursachen Origin-Fehler.

Methode 1 – Cloudflare-IP-Whitelist im BT-Panel (am einfachsten)

Mit BT-Panel (aaPanel) ist die Einrichtung besonders einfach. Das Nginx-Firewall-Plugin erlaubt Whitelist-Konfiguration per Klick – ohne manuelle Config-Dateien.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Schritt 1: Nginx-Firewall-Plugin installieren

BT-Panel öffnen, links Software Store, Kategorie Third-Party Apps, Nginx Free Firewall suchen. Falls nicht installiert: Installieren – dauert nur Sekunden.

Schritt 2: IP-Whitelist konfigurieren

Nach der Installation Einstellungen der Nginx-Firewall öffnen.

1. Links Global Settings
2. Bereich IP Whitelist, Settings
3. Im Dialog nacheinander alle Cloudflare-IPv4-Blöcke hinzufügen

Tipp: BT-Panel verlangt Start-IP und End-IP. Die CF-Liste liefert CIDR (z. B. 173.245.48.0/20). Umrechnung mit Online-Tools („CIDR to IP range“). Beispiel: 173.245.48.0/20 → 173.245.48.0 bis 173.245.63.255.

15 Blöcke manuell umzurechnen ist mühsam. Oft gibt es fertige Import-Listen in Blogs – kopieren und einfügen.
4. Nach allen Blöcken Import
5. Nginx neu starten

Hinweis: BT-Panel unterstützt derzeit nur IPv4. IPv6-Whitelist geht nur über Nginx-Config oder Methode 2.

Schritt 3: Konfiguration prüfen

Nach der Einrichtung testen:

• Mit Mobilfunk (Nicht-CF) direkt die Origin-IP aufrufen – erwartet: 403 Forbidden
• Über die Domain (CF-Proxy) – erwartet: normale Anzeige

Bei 502: Whitelist unvollständig oder Regeln nicht gespeichert. Firewall aktiv? Alle CF-Blöcke eingetragen?

Methode 2 – Reine Nginx-Whitelist (flexibler)

Ohne BT-Panel oder für mehr Kontrolle: direkte Nginx-Konfiguration. Unterstützt IPv6 – umfassender als BT-Panel.

Schritt 1: Cloudflare-IP-Konfigurationsdatei anlegen

Per SSH eine dedizierte Whitelist-Datei erstellen:

sudo nano /etc/nginx/cloudflare-whitelist.conf

Inhalt:

# Cloudflare IPv4-Ranges
allow 173.245.48.0/20;
allow 103.21.244.0/22;
allow 103.22.200.0/22;
allow 103.31.4.0/22;
allow 141.101.64.0/18;
allow 108.162.192.0/18;
allow 190.93.240.0/20;
allow 188.114.96.0/20;
allow 197.234.240.0/22;
allow 198.41.128.0/17;
allow 162.158.0.0/15;
allow 104.16.0.0/13;
allow 104.24.0.0/14;
allow 172.64.0.0/13;
allow 131.0.72.0/22;
# Cloudflare IPv6-Ranges
allow 2400:cb00::/32;
allow 2606:4700::/32;
allow 2803:f800::/32;
allow 2405:b500::/32;
allow 2405:8100::/32;
allow 2a06:98c0::/29;
allow 2c0f:f248::/32;
# Alle anderen IPs ablehnen
deny all;

Speichern (Ctrl+O, Ctrl+X).

Schlüsselpunkt: deny all; am Ende ist Pflicht – alle nicht erlaubten IPs werden abgewiesen. Diese Zeile darf nicht fehlen.

Schritt 2: Whitelist in der Site-Konfiguration einbinden

Site-Config bearbeiten – typisch /etc/nginx/sites-available/ (Debian/Ubuntu) oder /etc/nginx/conf.d/ (CentOS):

sudo nano /etc/nginx/sites-available/your-site.conf

Im server-Block:

server {
    listen 80;
    server_name example.com;
    # Cloudflare-Whitelist einbinden
    include /etc/nginx/cloudflare-whitelist.conf;
    # Weitere Konfiguration...
    root /var/www/html;
    index index.html;
}

Bei HTTPS (Port 443) dieselbe include-Zeile im entsprechenden server-Block.

Schritt 3: Nginx testen und neu laden

Syntax prüfen:

sudo nginx -t

Bei syntax is ok und test is successful:

sudo systemctl reload nginx

Fertig.

Vorteil: Separate Datei – IP-Updates nur in cloudflare-whitelist.conf, mehrere Sites können dieselbe Datei nutzen. Flexibler als BT-Panel, mit IPv6.

Methode 3 – Cloudflare Origin-Server-Zertifikat (am sichersten)

Die ersten beiden Methoden sind bereits sicher. Bei sehr hohen Anforderungen kommt Origin-Server-Zertifikatsprüfung dazu. Selbst bei geleakter Origin-IP: Zertifikatsfehler, keine Verbindung.

Was ist ein Cloudflare Origin-Server-Zertifikat

Kurz: Ein von Cloudflare signiertes TLS-Zertifikat nur für die Verbindung zwischen Cloudflare und Origin. Browser vertrauen ihm nicht (nur CF) – Direktzugriff auf die Origin-IP zeigt Zertifikatswarnung, Verbindung scheitert.

Mit IP-Whitelist: doppelter Schutz – Whitelist blockiert Nicht-CF-Traffic, Zertifikat stellt sicher, dass nur CF eine verschlüsselte Verbindung aufbaut.

Schritt 1: Origin-Server-Zertifikat erzeugen

Cloudflare-Dashboard, Domain wählen, SSL/TLS → Origin Server.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

1. Create Certificate
2. Domain schützen (Wildcard möglich, z. B. *.example.com)
3. Gültigkeit maximal 15 Jahre
4. Erstellen

Cloudflare liefert:

• Origin Certificate: PEM-Zertifikat
• Private Key: zugehöriger Schlüssel

Auf dem Server speichern, z. B.:

sudo nano /etc/nginx/certs/cloudflare.crt
# Origin-Zertifikat einfügen
sudo nano /etc/nginx/certs/cloudflare.key
# Private Key einfügen

Schlüssel schützen:

sudo chmod 600 /etc/nginx/certs/cloudflare.key

Schritt 2: Nginx mit Origin-Zertifikat konfigurieren

Site-Config bearbeiten, im HTTPS-server-Block:

server {
    listen 443 ssl http2;
    server_name example.com;
    # Cloudflare Origin-Zertifikat
    ssl_certificate /etc/nginx/certs/cloudflare.crt;
    ssl_certificate_key /etc/nginx/certs/cloudflare.key;
    # IP-Whitelist einbinden
    include /etc/nginx/cloudflare-whitelist.conf;
    # Weitere Konfiguration...
}

Für strengere Prüfung optional Client-Zertifikat (CF-Client-Zertifikat herunterladen):

ssl_client_certificate /etc/nginx/certs/cloudflare-client.crt;
ssl_verify_client on;

Testen und neu laden:

sudo nginx -t && sudo systemctl reload nginx

Hinweis: Für normale Sites reicht die IP-Whitelist. Origin-Zertifikat nur bei sehr hohen Sicherheitsanforderungen.

Konfiguration testen und häufige Probleme

Nach der Einrichtung unbedingt testen.

So testen Sie die Konfiguration

Methode 1: Nicht-CF-Traffic direkt auf Origin-IP
Mit Mobilfunk (oder anderem Nicht-Cloudflare-Netz) im Browser die Origin-IP aufrufen, z. B. http://123.45.67.89. Korrekt konfiguriert: 403 Forbidden.

Methode 2: curl
Auf dem lokalen Rechner (nicht Server):

curl -I http://Ihre-Origin-IP

Erwartet: 403 Forbidden.

Methode 3: Zugriff über Domain (CF-Proxy)
Domain im Browser, z. B. https://example.com – sollte normal laden. Auch hier 403: Konfigurationsfehler.

Häufige Probleme und Lösungen

Problem 1: 502 nach der Konfiguration
Mögliche Ursachen:

• Unvollständige Whitelist, CF-IPs fehlen
• Syntaxfehler in der Nginx-Config

Lösung:

1. sudo nginx -t für Syntax
2. Error-Log: sudo tail -f /var/log/nginx/error.log
3. Alle 15 IPv4- und 7 IPv6-Blöcke prüfen

Problem 2: 403 auch über CF
Mögliche Ursachen:

• deny all; vor den allow-Regeln
• CF-Origin-IP nicht in der Whitelist (CF hat IPs aktualisiert)

Lösung:

1. allow vor deny all; sicherstellen
2. https://www.cloudflare.com/ips/ auf Aktualität prüfen

Problem 3: BT-Panel-Import wirkt nicht
Mögliche Ursachen:

• Firewall-Plugin nicht aktiv
• Regeln nicht gespeichert oder Nginx nicht neu gestartet

Lösung:

1. Nginx-Firewall aktiv (grünes Icon)
2. Nginx im BT-Panel neu starten
3. Firewall-Log auf Fehler prüfen

Problem 4: IPv6 umgeht die Whitelist
Mögliche Ursache:

• Nur IPv4 konfiguriert, IPv6 vergessen

Lösung:

1. CF-IPv6-Blöcke zur Whitelist
2. Oder IPv6 in der Firewall deaktivieren (falls nicht benötigt)

Weitere Sicherheitsempfehlungen

Whitelist ist der erste Schritt. Zusätzlich sinnvoll:

• SSH-Port ändern: Port 22 wird oft gescannt – hohen Port wählen
• System aktuell halten: Patches und Sicherheitsupdates
• Nginx-Version verbergen: in nginx.conf server_tokens off;
• Cloudflare Under Attack Mode: bei starken Angriffen die 5-Sekunden-Challenge

Cloudflare-IP-Liste pflegen und aktualisieren

Die Cloudflare-IP-Liste ändert sich – neue oder angepasste Blöcke. Ohne Update blockieren Sie neue CF-IPs, Zugriffe schlagen fehl.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Warum regelmäßige Updates

Cloudflare betreibt weltweit hunderte Rechenzentren – IP-Ranges wachsen mit der Infrastruktur. Nicht täglich, aber alle paar Monate Updates.

Mit veralteter Whitelist werden neue CF-Origin-IPs abgewiesen – Nutzer in manchen Regionen sehen Fehler, Origin-Anfragen scheitern.

Manuelles Update

Alle 2–3 Monate https://www.cloudflare.com/ips/ prüfen, neue Blöcke vergleichen.

Bei Updates:

1. Whitelist-Config bearbeiten
2. Neue Blöcke hinzufügen
3. sudo nginx -t
4. sudo systemctl reload nginx

Automatisches Update-Skript (optional)

Bash-Skript zum Abruf der neuesten IP-Liste und Config-Update:

#!/bin/bash
# Cloudflare IP-Whitelist Auto-Update
CF_IPV4_URL="https://www.cloudflare.com/ips-v4"
CF_IPV6_URL="https://www.cloudflare.com/ips-v6"
NGINX_CONF="/etc/nginx/cloudflare-whitelist.conf"
BACKUP_CONF="/etc/nginx/cloudflare-whitelist.conf.bak"
# Backup
cp $NGINX_CONF $BACKUP_CONF
# Neue Config
echo "# Cloudflare IP Whitelist - Auto-generated on $(date)" > $NGINX_CONF
echo "" >> $NGINX_CONF
# IPv4
echo "# IPv4 ranges" >> $NGINX_CONF
curl -s $CF_IPV4_URL | sed 's/^/allow /' | sed 's/$/;/' >> $NGINX_CONF
echo "" >> $NGINX_CONF
# IPv6
echo "# IPv6 ranges" >> $NGINX_CONF
curl -s $CF_IPV6_URL | sed 's/^/allow /' | sed 's/$/;/' >> $NGINX_CONF
echo "" >> $NGINX_CONF
# Alle anderen ablehnen
echo "# Deny all other IPs" >> $NGINX_CONF
echo "deny all;" >> $NGINX_CONF
# Test
if nginx -t; then
    echo "Syntax OK, Nginx neu laden..."
    systemctl reload nginx
    echo "✓ Cloudflare-Whitelist erfolgreich aktualisiert!"
else
    echo "✗ Config-Fehler, Backup wiederherstellen..."
    cp $BACKUP_CONF $NGINX_CONF
    echo "Original wiederhergestellt – Fehler prüfen"
fi

Speichern als /root/update-cf-whitelist.sh, ausführbar machen:

chmod +x /root/update-cf-whitelist.sh

Cron-Job für monatliche Ausführung:

crontab -e

Zeile hinzufügen:

0 3 1 * * /root/update-cf-whitelist.sh >> /var/log/cf-whitelist-update.log 2>&1

Monatlich am 1. um 3 Uhr – Log in /var/log/cf-whitelist-update.log.

Hinweis: Vor dem ersten Cron-Lauf manuell testen. Ein fehlerhaftes Skript kann die Config beschädigen.

Fazit

Kernbotschaft: Origin-Schutz braucht eine Cloudflare-Whitelist.

Drei Methoden im Überblick:

• BT-Panel-Whitelist: Am einfachsten, per Klick – für Einsteiger. Nur IPv4.
• Reines Nginx: Flexibler, IPv6, zentrale Config – für Linux-Grundkenntnisse.
• Origin-Server-Zertifikat: Am sichersten, doppelter Schutz – für hohe Anforderungen.

Nach der Konfiguration testen: Mobilfunk direkt auf Origin-IP → 403 = Erfolg. Dann Domain prüfen.

Cloudflare-IPs ändern sich – regelmäßig prüfen oder Skript nutzen. Monate ohne Update: neue CF-Blöcke fehlen, Zugriffe brechen ab.

Wenn der Artikel geholfen hat, teilen Sie ihn mit anderen Cloudflare-Nutzern. Gemeinsam Origin absichern – Angriffe werden schwerer.

Prüfen Sie jetzt, ob Ihre Origin-IP bereits geleakt ist – myssl.com oder ähnliche SSL-Checker. Bei Leak: Whitelist nach diesem Guide einrichten. Besser spät als nie.