Cloudflare auf Netcup einrichten (Full Strict SSL, echte Besucher-IPs & Origin-Firewall-Lock)

Ist Ihre Domain über Netcup registriert (einschließlich der kostenlosen Inklusiv-.de-Domains aus einem Netcup Webhosting-Tarif), melden Sie sich im Customer Control Panel (customercontrolpanel.de) → Domains → Domain auswählen → Name Server an, wählen Eigene Nameserver und tragen die beiden von Cloudflare zugewiesenen Nameserver ein (z. B. ada.ns.cloudflare.com und bob.ns.cloudflare.com). Ihre Domainregistrierung und Abrechnung verbleiben dabei vollständig bei Netcup; lediglich die autoritative DNS-Auflösung und das Anycast-Edge-Routing werden an Cloudflare delegiert.

Wichtiger DNSSEC-Hinweis vor dem Umschalten der Nameserver: Falls DNSSEC zuvor auf den Netcup-Standard-Nameservern aktiviert war, ist in der übergeordneten Registry (z. B. DENIC für .de oder Verisign für .com) noch der öffentliche DS-Schlüssel-Hash des Netcup-Signierschlüssels hinterlegt. Wenn Sie die Nameserver auf Cloudflare umstellen, ohne DNSSEC zuvor im CCP zu deaktivieren, stufen validierende DNS-Resolver wie 1.1.1.1 und 8.8.8.8 die Antworten der neuen Cloudflare-Nameserver als kryptografisch ungültig (SERVFAIL) ein. Schalten Sie DNSSEC im CCP daher vor dem Wechsel aus, warten Sie bis Cloudflare die Zone als Active meldet, und aktivieren Sie DNSSEC anschließend im Cloudflare-Dashboard neu.

Legen Sie in der Cloudflare-DNS-Verwaltung sowohl einen A-Record (auf die öffentliche /32-IPv4-Adresse Ihres Netcup-Servers) als auch einen AAAA-Record (auf die primäre IPv6-Adresse Ihres /64-Subnetzes, z. B. 2a03:4000:xx:xx::1) mit aktiviertem Proxy-Status (Orangefarbene Wolke) an. Da das autonome System von Netcup (AS197540 Anexia/Netcup) an den großen europäischen Internetknoten in Frankfurt (DE-CIX), Wien (VIX) und Amsterdam (AMS-IX) direkt mit Cloudflare peert, beträgt die Netzwerklatenz zwischen den Cloudflare-Edge-Knoten und Ihrem Netcup-Server in Nürnberg oder Wien meist weniger als 2 bis 4 Millisekunden – über IPv6 oft sogar noch stabiler als über IPv4.

Beachten Sie jedoch eine wichtige Protokollgrenze der orangefarbenen Proxy-Wolke: Im Standardmodus leitet Cloudflare ausschließlich HTTP/HTTPS-Traffic auf einer festen Liste von Web-Ports (wie 80, 443, 2053, 8080, 8443) weiter, jedoch niemals rohen SSH-Traffic (Port 22), SMTP/IMAP-Mailverkehr oder WireGuard-UDP-Pakete. Wenn Sie versuchen, sich per ssh [email protected] über einen geproxten Hostnamen zu verbinden, landet Ihr SSH-Client auf dem Cloudflare-Anycast-Edge und bricht mit einem Timeout ab. Verbinden Sie sich für administrative Zwecke daher entweder direkt mit Ihrer Server-IP oder legen Sie eine separate Subdomain mit grauer Wolke (DNS Only) an:

• ▪ IPv4-Eintrag: Typ A, Name @ (und www), Inhalt 203.0.113.10 (Ihre öffentliche Netcup IPv4 /32-Adresse), Proxy-Status: Proxied (Orangefarbene Wolke).
• ▪ IPv6-Eintrag: Typ AAAA, Name @ (und www), Inhalt 2a03:4000:xx:xx::1 (Ihre primäre Netcup-IPv6-Adresse aus Ihrem /64-Subnetz), Proxy-Status: Proxied.
• ▪ SSH-Subdomain-Ausnahme: Da Cloudflares Standard-HTTP-Proxy keinen SSH-Traffic auf Port 22 weiterleitet, verbinden Sie sich per SSH entweder direkt über Ihre IPv4/IPv6-Adresse oder legen Sie einen separaten Eintrag ssh.example.com mit dem Status DNS Only (Graue Wolke) an.

Stellen Sie im Cloudflare-Dashboard unter SSL/TLS → Übersicht den Verschlüsselungsmodus sofort auf Full (Strict) / Vollständig (Strikt). Warum ist der veraltete Modus Flexible / Flexibel so gefährlich? Im Modus „Flexible“ terminiert Cloudflare zwar HTTPS gegenüber dem Besucher, baut die Verbindung zu Ihrem Netcup-Server in Nürnberg oder Wien jedoch unverschlüsselt über Port 80 (HTTP) auf. Zum einen werden dadurch Passwörter, Session-Cookies und API-Tokens im Klartext über das öffentliche Transitnetz übertragen; zum anderen erkennt Ihr Nginx- oder WordPress-Server eine unverschlüsselte Anfrage auf Port 80, antwortet mit 301 Moved Permanently -> https://... und schickt den Browser in eine endlose ERR_TOO_MANY_REDIRECTS-Weiterleitungsschleife.

Im Modus Full (Strict) verlangt Cloudflare auf Port 443 Ihres Netcup-Servers ein kryptografisch gültiges Zertifikat, das entweder von einer öffentlichen Zertifizierungsstelle (wie Let’s Encrypt via Certbot) oder von der Cloudflare Origin CA ausgestellt wurde. Für Server, die ausschließlich hinter Cloudflare betrieben werden, können Sie unter SSL/TLS → Ursprungsserver ein bis zu 15 Jahre gültiges Cloudflare Origin CA Zertifikat (inklusive Wildcard *.example.com) generieren und in Nginx hinterlegen – damit entfällt jeglicher Aufwand für eine regelmäßige ACME-Zertifikatserneuerung.

Selbst mit Full (Strict) bleibt jedoch eine Angriffslücke offen, wenn Ihr Netcup-Server auf Port 443 Verbindungen von beliebigen IP-Adressen im Internet annimmt: Über historische DNS-Datenbanken (wie Censys, Shodan oder SecurityTrails) können Angreifer Ihre echte Netcup-IPv4-Adresse ermitteln, in einem Angriffs-Skript curl --resolve example.com:443:203.0.113.10 aufrufen und Ihre Cloudflare-WAF, Bot-Erkennung sowie DDoS-Filter komplett umgehen.

Die eleganteste kryptografische Lösung hierfür ist Authenticated Origin Pulls (gegenseitiges TLS / mTLS): Wenn Sie in Ihrem Nginx-Serverblock ssl_client_certificate /etc/nginx/certs/cloudflare-origin-pull-ca.pem; und ssl_verify_client on; aktivieren, muss sich der verbindende Client während des TLS-1.3-Handshakes mit einem von Cloudflare signierten Client-Zertifikat ausweisen. Direkte Zugriffe auf Ihre Netcup-IP scheitern bereits im TLS-Handshake, noch bevor eine einzige HTTP-Zeile Ihre Webanwendung erreicht. Aktivieren Sie ergänzend im Cloudflare-Dashboard unter Caching → Tiered Cache die Option Smart Tiered Cache, damit nur ein einziger regionaler Upper-Tier-Knoten (z. B. Frankfurt) fehlende Assets von Ihrem Netcup-Server abruft:

# Offizielles Cloudflare Authenticated Origin Pull Root-CA-Zertifikat herunterladen
sudo mkdir -p /etc/nginx/certs
sudo curl -fsSL https://developers.cloudflare.com/ssl/static/authenticated_origin_pull_ca.pem \
  -o /etc/nginx/certs/cloudflare-origin-pull-ca.pem

# Fügen Sie innerhalb Ihres /etc/nginx/sites-available/example.com.conf server { listen 443 ssl; ... } Blocks hinzu:
# ssl_client_certificate /etc/nginx/certs/cloudflare-origin-pull-ca.pem;
# ssl_verify_client on;

sudo nginx -t && sudo systemctl reload nginx

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Da Cloudflare als Reverse-Proxy agiert, wird jede TCP-Verbindung zu Ihrem Netcup-Server von einem Cloudflare-Edge-Router (z. B. aus dem Netz 172.64.0.0/13 oder 2606:4700::/32) geöffnet. Ohne das Nginx-Modul ngx_http_realip_module enthält die interne Nginx-Variable $remote_addr daher ausschließlich die IP-Adresse des Cloudflare-Rechenzentrums statt der echten IP Ihres Besuchers.

Die Folgen einer fehlenden RealIP-Konfiguration im Produktionsbetrieb sind gravierend: Erstens sind Ihre /var/log/nginx/access.log-Protokolle für Sicherheitsanalysen wertlos, da sämtliche Zugriffe scheinbar von denselben 20 Cloudflare-IPs stammen. Zweitens – und noch kritischer – teilen sich tausende legitime Besucher denselben Bucket in Ihrer Nginx-limit_req_zone oder Ihren Fail2ban-Jails. Löst ein einziger Bot fünf fehlerhafte Logins über den Frankfurter Cloudflare-Knoten aus, sperrt Fail2ban die Cloudflare-Edge-IP – und schneidet Ihr gesamtes deutschsprachiges Publikum mit Error 522 Connection Timed Out von Ihrer Website ab!

Gleichzeitig darf Ihre Webanwendung den HTTP-Header CF-Connecting-IP oder X-Forwarded-For niemals ungeprüft auslesen: Da HTTP-Header gewöhnlicher Text sind, könnte ein Angreifer sonst einen gefälschten Header CF-Connecting-IP: 127.0.0.1 senden, um IP-Sperren oder Admin-Freigaben auszuhebeln. Das Modul ngx_http_realip_module löst dieses Dilemma durch eine strikte Vertrauenskette: Über die Anweisungen set_real_ip_from <CIDR>; kombiniert mit real_ip_header CF-Connecting-IP; und real_ip_recursive on; überschreibt Nginx $remote_addr nur dann mit der Adresse aus CF-Connecting-IP, wenn das TCP-Paket nachweislich von einem autorisierten Cloudflare-Subnetz stammt.

Erstellen Sie das folgende Wartungsskript unter /usr/local/sbin/update-cloudflare-realip.sh, das die aktuellen IPv4- und IPv6-Netzlisten von Cloudflare abruft, in einer temporären Datei vorbereitet, die Nginx-Syntax mit nginx -t prüft und die Worker anschließend automatisch neu lädt:

cat << 'EOF' | sudo tee /usr/local/sbin/update-cloudflare-realip.sh
#!/usr/bin/env bash
set -euo pipefail

CONF_FILE="/etc/nginx/conf.d/cloudflare-realip.conf"
TMP_FILE="$(mktemp)"

# Automatisch generierte Cloudflare RealIP-Konfiguration schreiben
echo "# Automatisch generierte Cloudflare RealIP-Konfiguration ($(date -u +%Y-%m-%dT%H:%M:%SZ))" > "${TMP_FILE}"

for ip in $(curl -fsSL https://www.cloudflare.com/ips-v4); do
  echo "set_real_ip_from ${ip};" >> "${TMP_FILE}"
done

for ip6 in $(curl -fsSL https://www.cloudflare.com/ips-v6); do
  echo "set_real_ip_from ${ip6};" >> "${TMP_FILE}"
done

echo "real_ip_header CF-Connecting-IP;" >> "${TMP_FILE}"
echo "real_ip_recursive on;" >> "${TMP_FILE}"

mv "${TMP_FILE}" "${CONF_FILE}"
chmod 0644 "${CONF_FILE}"
nginx -t && systemctl reload nginx
EOF

sudo chmod +x /usr/local/sbin/update-cloudflare-realip.sh
sudo /usr/local/sbin/update-cloudflare-realip.sh

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful