WordPress betreibt über 40 % des Webs und ist damit das meistangegriffene CMS durch automatisierte Bots, Script-Kiddies und ausgereifte Angreifer gleichermaßen. Jede ungeschützte WordPress-Website wird täglich mit Tausenden bösartiger Anfragen konfrontiert — Brute-Force-Anmeldeversuche, XML-RPC-Verstärkungsangriffe, SQL-Injection-Sondierungen und Directory-Traversal-Scans. Cloudflares Web Application Firewall (WAF) bietet eine leistungsstarke kostenlose Verteidigungsschicht, die diese Angriffe am Edge stoppt, bevor sie Ihren Server erreichen. In dieser Anleitung konfigurieren Sie benutzerdefinierte WAF-Regeln, die die häufigsten WordPress-Angriffsvektoren blockieren.

Voraussetzungen

  • Ein Cloudflare-Konto (der kostenlose Tarif reicht für bis zu 5 benutzerdefinierte Regeln)
  • Das DNS Ihrer Domain wird von Cloudflare verwaltet (Orange-Cloud-Proxy aktiviert)
  • Eine laufende WordPress-Installation
  • Admin-Zugriff auf das Cloudflare-Dashboard
  • Ihre aktuelle öffentliche IP-Adresse (für die Freischaltung des Admin-Zugriffs)

Warum WordPress WAF-Schutz braucht

WordPress-Websites sind einem unaufhörlichen Ansturm automatisierter Angriffe ausgesetzt. Laut Wordfence-Daten verzeichnet eine typische WordPress-Website über 90.000 bösartige Anmeldeversuche pro Monat. Die am häufigsten ausgenutzten Endpunkte sind:

  • xmlrpc.php — wird für Brute-Force-Verstärkung (eine Anfrage kann Hunderte von Passwörtern testen), DDoS über Pingback-Missbrauch und SSRF-Angriffe verwendet
  • wp-login.php — Ziel von Credential-Stuffing-Bots, die geleakte Passwortlisten durchlaufen
  • wp-admin/ — wird auf nicht authentifizierten Zugriff auf Admin-Funktionen geprüft
  • wp-json/wp/v2/ — REST API-Enumeration legt Benutzernamen und Inhaltsstruktur offen
  • Query-Strings — SQL-Injection-Versuche über ?id=1 UNION SELECT, Path-Traversal über ../../etc/passwd

Eine Server-Firewall wie iptables sieht nur IP-Adressen. Cloudflare WAF untersucht HTTP-Anfragen auf Layer 7 — es kann URI-Pfade, Query-Strings, Header, Anfragemethoden und User-Agents abgleichen. Das ermöglicht Ihnen, präzise Regeln zu schreiben, die Angriffe blockieren, ohne legitime Besucher zu beeinträchtigen.

Wesentliche WAF-Regeln

Navigieren Sie zu Ihrem Cloudflare-Dashboard: Security > WAF > Custom rules. Sie erstellen diese Regeln in der Reihenfolge der Priorität.

Regel 1: xmlrpc.php blockieren

Dies ist die wirkungsvollste einzelne Regel. xmlrpc.php macht den Großteil des Brute-Force-Traffics auf den meisten WordPress-Websites aus.

Expression:
(http.request.uri.path eq "/xmlrpc.php")

Action: Block

Wenn Sie auf Jetpack oder die WordPress-Mobile-App angewiesen sind, ändern Sie die Aktion auf Managed Challenge anstelle von Block. Aber wenn Sie xmlrpc vollständig deaktivieren können, blockieren Sie es.

Regel 2: Challenge für wp-login.php

Anstatt die Anmeldeseite komplett zu blockieren, verwenden Sie eine Managed Challenge, damit legitime Administratoren weiterhin durchkommen, während Bots gestoppt werden.

Expression:
(http.request.uri.path eq "/wp-login.php")

Action: Managed Challenge

Dies erzwingt Cloudflares Smart-Challenge (CAPTCHA oder JS-Challenge) bei jeder Anfrage an die Anmeldeseite. Automatisierte Bots scheitern an der Challenge; echte Menschen bestehen sie transparent.

Regel 3: wp-admin per IP einschränken

Schränken Sie den Admin-Bereich auf Ihre IP-Adresse ein. Das entscheidende Detail ist hier der Ausschluss von admin-ajax.php, das WordPress für Frontend-AJAX-Aufrufe verwendet (Kontaktformulare, WooCommerce-Warenkorbaktualisierungen usw.).

Expression:
(http.request.uri.path contains "/wp-admin"
  and not http.request.uri.path contains "admin-ajax.php"
  and not ip.src in {203.0.113.50})

Action: Block

Ersetzen Sie 203.0.113.50 durch Ihre tatsächliche IP. Sie können mehrere IPs in einer Liste angeben: {203.0.113.50 198.51.100.25}.

Regel 4: SQL-Injection und Path-Traversal blockieren

Fangen Sie häufige Injection-Muster in der vollständigen URI ab, einschließlich Query-Strings.

Expression:
(http.request.uri contains "union select"
  or http.request.uri contains "concat("
  or http.request.uri contains "../"
  or http.request.uri contains "eval("
  or http.request.uri contains "<script"
  or http.request.uri contains "etc/passwd")

Action: Block

Diese Regel erfasst die häufigsten SQLi- und XSS-Payloads. Die Muster decken UNION-basierte Injection, Path-Traversal, JavaScript-Injection und Local-File-Inclusion-Versuche ab.

Regel 5: Bösartige User-Agents blockieren

Viele Angriffstools verwenden identifizierbare User-Agents. Kombinieren Sie die Bot-Blockierung in einer Regel, um Ihre Regel-Slots im kostenlosen Tarif zu sparen.

Expression:
(http.request.uri.path contains "/wp-"
  and (http.user_agent contains "sqlmap"
    or http.user_agent contains "nikto"
    or http.user_agent contains "wpscan"
    or http.user_agent contains "masscan"
    or http.user_agent eq ""))

Action: Block

Leere User-Agents auf WordPress-Endpunkten sind fast immer bösartige Scanner. Diese Regel blockiert sie zusammen mit bekannten Angriffstool-Signaturen.

Kostenlos vs. Pro vs. Business WAF-Funktionen

FunktionKostenlosPro (20 $/Monat)Business (200 $/Monat)
Benutzerdefinierte WAF-Regeln520100
Verwaltete Regelsätze (OWASP)NeinJaJa
Rate-Limiting-Regeln11050
Bot-ManagementEinfachErweitertFortgeschritten
Benutzerdefinierte FehlerseitenNeinJaJa
WAF-AnalytikEinfache EventsDetailliertVollständig mit Logs
IP-ZugriffsregelnUnbegrenztUnbegrenztUnbegrenzt
Antwort-Header-ÄnderungNeinJaJa

Für die meisten WordPress-Websites deckt der kostenlose Tarif mit 5 gut gestalteten benutzerdefinierten Regeln 90 % des Angriffstraffics ab. Ein Upgrade auf Pro lohnt sich, wenn Sie verwaltete OWASP-Regelsätze oder mehr Regel-Slots benötigen.

Praxisszenario

Sie betreiben eine WordPress-E-Commerce-Website mit WooCommerce, die 500 Bestellungen pro Tag verarbeitet. Ihre Server-Logs zeigen täglich über 1.200 fehlgeschlagene Anmeldeversuche auf wp-login.php, Ihre xmlrpc.php wird 8.000 Mal am Tag von Botnets getroffen, und Sie haben SQL-Injection-Strings in Ihren Query-Logs bemerkt. Ihr Hosting-Anbieter warnt Sie vor CPU-Spitzen durch die Verarbeitung all dieser bösartigen Anfragen.

Nach Aktivierung der fünf obigen WAF-Regeln blockiert Cloudflare 95 % dieses Traffics am Edge. Ihre Server-CPU sinkt um 40 %, die Ladezeiten verbessern sich, weil Ihre PHP-Worker nicht mehr mit der Verarbeitung von Angriffsanfragen beschäftigt sind, und Ihre Hosting-Kosten bleiben stabil statt hochzuskalieren. Die Managed Challenge auf wp-login.php stoppt Credential Stuffing, während sich Ihr Redaktionsteam problemlos anmeldet. Die wp-admin-IP-Beschränkung bedeutet: Selbst wenn ein Angreifer Zugangsdaten erlangt, kann er das Dashboard von seiner IP aus nicht erreichen.

Rate Limiting für WordPress

Rate Limiting fügt Ihrem Schutz eine zeitbasierte Dimension hinzu. Navigieren Sie zu Security > WAF > Rate limiting rules.

Rate Limit für die Anmeldeseite

Expression:
(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")

Rate: 5 requests per 10 seconds
Action: Block for 600 seconds (10 minutes)
Counting expression: Same as rule expression

Rate Limit für die REST API

Expression:
(http.request.uri.path contains "/wp-json/")

Rate: 30 requests per 10 seconds
Action: Managed Challenge

Dies verhindert API-Enumeration und Missbrauch, während die normale REST API-Nutzung durch Themes und Plugins erlaubt bleibt.

Fehlerbehebung

admin-ajax.php muss ausgeschlossen werden — WordPress verwendet admin-ajax.php für Frontend-AJAX-Anfragen, auch für nicht angemeldete Besucher. Kontaktformulare, WooCommerce-Warenkorb-Funktionen und Infinite Scroll nutzen diesen Endpunkt. Ihn hinter einer IP-Beschränkung zu blockieren, bricht Ihr gesamtes Frontend.

WooCommerce REST API — wenn Sie die WooCommerce REST API für externe Integrationen nutzen (Versandanbieter, Bestandssynchronisation, Kassensysteme), stellen Sie sicher, dass Ihr Rate Limiting auf /wp-json/ diese Dienste nicht blockiert. Setzen Sie deren IPs auf die Whitelist oder verwenden Sie einen höheren Schwellenwert.

Cron und geplante Aufgaben — wp-cron.php wird von Cloudflare-gecachten Seiten aufgerufen. Wenn Sie serverseitigen Cron verwenden (empfohlen), können Sie den externen Zugriff auf wp-cron.php per WAF-Regel blockieren.

Plugin-Updates und Datei-Uploads — einige Plugins senden während automatischer Updates Anfragen an wp-admin-Pfade. Ihre IP-Beschränkungsregel handhabt dies, solange der Server selbst nicht über einen externen Dienst geleitet wird, der die Quell-IP ändert.

Vorsicht bei Ländersperren — vermeiden Sie das Blockieren ganzer Länder, es sei denn, Sie haben dort wirklich keine Nutzer. Länderbezogene Sperren können versehentlich Suchmaschinen-Crawler blockieren, die über diese Länder geroutet werden, und so Ihre SEO beeinträchtigen.

Gründlich testen — öffnen Sie nach dem Aktivieren der Regeln ein Inkognito-Fenster und testen Sie: Besuchen Sie die Startseite, navigieren Sie zu einer Produktseite, senden Sie ein Kontaktformular ab und melden Sie sich bei wp-admin an. Prüfen Sie Security > Events auf False Positives.

Zusammenfassung

  • Blockieren Sie xmlrpc.php vollständig — es ist der am häufigsten missbrauchte WordPress-Endpunkt und die meisten Websites benötigen ihn nicht
  • Verwenden Sie Managed Challenges auf wp-login.php, um Bots zu stoppen und gleichzeitig menschliche Administratoren durchzulassen
  • Beschränken Sie wp-admin per IP, aber schließen Sie immer admin-ajax.php aus, um die Frontend-Funktionalität nicht zu beeinträchtigen
  • Fügen Sie SQL-Injection- und XSS-Mustererkennung hinzu, um häufige Injection-Payloads am Edge abzufangen
  • Konfigurieren Sie Rate Limiting für Anmelde- und REST API-Endpunkte, um Brute-Force-Versuche zu drosseln
  • Der kostenlose Cloudflare-Tarif bietet 5 benutzerdefinierte Regeln — genug, um die kritische WordPress-Angriffsfläche abzudecken
  • Überwachen Sie die Security Events nach dem Bereitstellen der Regeln und passen Sie bei False Positives an
  • Erwägen Sie Cloudflare Access (Zero Trust) für Szenarien mit dynamischen IPs anstelle von IP-Whitelisting

Verwandte Artikel