Absicherung von WordPress XML-RPC- und REST-API-Endpunkten gegen Botnet-Angriffe

Botnets nehmen xmlrpc.php aus drei Gründen ins Visier, die sich gegenseitig verstärken: Der Speicherort ist vorhersehbar, die Datei ist standardmäßig aktiv, und sie ist weit offen für system.multicall-Missbrauch. Letzteres wiegt schwerer, als den meisten Website-Betreibern bewusst ist.

Angreifer bündeln Tausende von Login-Versuchen in einer einzigen Anfrage, was Rate Limiting vollständig umgeht und das, was wie geringer Traffic aussieht, in eine Credential-Stuffing-Operation verwandelt.

Die Lösung hängt davon ab, was tatsächlich benötigt wird. Wenn nichts in Ihrem Stack auf XML-RPC angewiesen ist, deaktivieren Sie es komplett. Fügen Sie dies in Ihre .htaccess-Datei ein, und der Endpunkt wird stillgelegt:

„`

Order Deny,Allow

Deny from all

„`

Der Einsatz von Jetpack ändert die Rechnung allerdings. Jetpack kommuniziert über XML-RPC, sodass eine pauschale Blockierung die Verbindung unterbricht. Der klügere Ansatz ist das Whitelisting der veröffentlichten IP-Bereiche von Automattic, während alles andere blockiert wird , gleiches Ergebnis für Angreifer, ohne Kollateralschäden an Ihrem Setup.

Die REST-API verdient ebenso viel Aufmerksamkeit. Im Auslieferungszustand antwortet WordPress auf `/wp-json/wp/v2/users` mit einer vollständigen Auflistung der Benutzer und liefert Botnet-Betreibern gültige Benutzernamen, bevor diese überhaupt begonnen haben. Ein Filter schließt diese Lücke:

„`php

add_filter(‚rest_endpoints‘, function($endpoints) {

if (isset($endpoints[‚/wp/v2/users‘])) {

unset($endpoints[‚/wp/v2/users‘]);

}

return $endpoints;

});

„`

Rate Limiting gehört an den Rand, nicht in die Anwendungsschicht. Cloudflare oder die WAF Ihres Hosters können Schwellenwerte durchsetzen, bevor Anfragen überhaupt PHP erreichen , genau dort sollte diese Reibung ansetzen.

Wird auch nur eines davon nicht angegangen, wird eine kompromittierte Website nicht nur gehackt , sie wird Teil der Infrastruktur, die selbst Angriffe ausführt.

Wichtigste Erkenntnisse

Die Vorhersehbarkeit von XML-RPC ist ihre größte Schwachstelle. Die Methode `system.multicall` ermöglicht es Botnetzen, Hunderte von Anmeldeversuchen in einer einzigen Anfrage zu bündeln, was das von Ihnen sorgfältig konfigurierte Rate-Limiting auf Anwendungsebene elegant umgeht. Wenn nichts auf Ihrer Website von XML-RPC abhängt , keine Jetpack-Verbindung, keine Veröffentlichung über eine mobile App , deaktivieren Sie es vollständig. Eine offene Angriffsfläche unter der Annahme zu belassen, dass Obskurität Schutz bietet, ist eine Wette, die Sie irgendwann verlieren werden.

Wenn Sie XML-RPC wirklich aktiv benötigen, beschränken Sie dessen Zugänglichkeit auf vertrauenswürdige IP-Bereiche, anstatt es weltweit zugänglich zu lassen. Jetpack veröffentlicht seine Server-IPs, sodass es unkompliziert ist, diese auf eine Whitelist zu setzen und alles andere zu blockieren, wodurch die Integration erhalten bleibt, ohne zu Missbrauch einzuladen.

Die REST-API verdient dieselbe Aufmerksamkeit. Nicht authentifizierte Anfragen an `/wp/v2/users` liefern Angreifern eine fertige Liste gültiger Benutzernamen, was ihre Brute-Force-Arbeit um die Hälfte reduziert, bevor sie überhaupt begonnen haben. Beschränken Sie diesen Endpunkt für nicht authentifizierte Benutzer, und dieser bestimmte Aufklärungsweg schließt sich sofort.

Benutzerdefinierte REST-Routen bergen ein eigenes Risiko, das leicht übersehen wird. Ein `permission_callback`, der auf `__return_true` gesetzt ist, bedeutet, dass jeder, der diese Route erreicht, vollen Zugriff auf alles hat, was sie offenlegt. Dies durch explizite Berechtigungsprüfungen zu ersetzen , `current_user_can(‚edit_posts‘)` oder welche Berechtigungsstufe auch immer sinnvoll ist , bedeutet, dass Autorisierung durchgesetzt und nicht vorausgesetzt wird.

Keine dieser Änderungen gehört in eine Produktivumgebung, bevor sie nicht zuvor in einer Staging-Umgebung validiert wurden. Regeln auf Serverebene gepaart mit Filtern auf Anwendungsebene schaffen echte Tiefenverteidigung, aber eine falsch konfigurierte Regel kann legitime Benutzer genauso effektiv aussperren, wie sie einen Angreifer stoppt.

Warum Botnets weiterhin XML-RPC von WordPress angreifen

WordPress wird standardmäßig mit aktivierter `xmlrpc.php` ausgeliefert, und genau diese oft übersehene Datei ist zu einem der zuverlässigsten Einstiegspunkte im Botnetz-Playbook geworden. Der Endpunkt befindet sich an einem vorhersehbaren Ort in jeder Standardinstallation, was bedeutet, dass automatisierte Credential-Stuffing-Kampagnen mit wenig technischem Aufwand seitens der Angreifer im großen Stil durchgeführt werden können.

Was ihn besonders gefährlich macht, ist die Methode `system.multicall`. Anstatt ein Passwort nach dem anderen zu testen, ermöglicht sie einem Angreifer, Tausende von Anmeldeversuchen in einer einzigen HTTP-Anfrage zu bündeln. Rate Limiting, das gegen normale Verkehrsmuster recht gut funktioniert, registriert ein derartiges Volumen kaum, bis es zu spät ist. Sicherheitsforscher bestätigen diese Angriffsfläche routinemäßig, indem sie den Endpunkt mit `system.listMethods` abfragen, was genau offenlegt, welche Funktionen wie system.multicall und pingback.ping öffentlich ohne Authentifizierung aufrufbar sind.

Es gibt noch eine weitere Ebene, die es zu verstehen gilt. Die Methode `wp.getUsersBlogs` gibt Angreifern eine einfache Möglichkeit, zu bestätigen, ob ein Benutzername tatsächlich existiert, noch bevor sie überhaupt anfangen, Passwörter zu erraten. Diese Aufklärung speist verteilte Sondierungskampagnen, die Versuche über Dutzende von IPs und Hunderte von Websites verteilen, was die Erkennung für alle, die die Logs überwachen, erheblich erschwert.

Die Funktionalität von `pingback.ping` verschärft die Sache in eine völlig andere Richtung. Anstatt Ihre Website anzugreifen, wird sie zur Waffe gemacht und zieht WordPress-Installationen in SSRF-Angriffe und Reflection-Attacken hinein, bei denen Ihr Server zum Werkzeug wird, das gegen jemand anderen eingesetzt wird.

Der Grund, warum Botnetze immer wieder zurückkommen, liegt nicht an Raffinesse, sondern an Mathematik. WordPress betreibt einen erheblichen Teil des Webs, sodass eine automatisierte Kampagne, die auf einen einzigen standardisierten Endpunkt zielt, einen enormen Pool potenzieller Opfer erreicht. Diese Logik zu verstehen, ist der erste Schritt, um nicht Teil dieses Pools zu werden.

Entscheiden Sie, ob Sie XML-RPC wirklich aktiviert haben müssen

Bevor Sie auch nur eine einzige Einstellung anfassen, brauchen Sie eine ehrliche Antwort auf eine Frage: Hängt momentan tatsächlich irgendetwas auf dieser Website von XML-RPC ab? Denken Sie an Jetpack, eine mobile App, ein Remote-Posting-Tool , etwas Konkretes und Bestätigtes, nicht Angenommenes.

Wenn Ihnen nichts in den Sinn kommt, ist dieses Schweigen Ihre Antwort. Den Endpunkt ohne einen verifizierten Grund aktiv zu halten, vergrößert schlicht die Angriffsfläche, und Botnetze warten nicht darauf, dass Sie es in Ihrem eigenen Tempo herausfinden. Falls Sie aktive Abhängigkeiten bestätigen, ziehen Sie in Betracht, den Zugriff durch selektive Methodenaktivierung einzuschränken, anstatt jede Funktion offen zu lassen.

Häufige Anwendungsfälle für XML-RPC

Bevor du zum Deaktivierungsschalter greifst, hol tief Luft und frag dich, was auf deiner Website eigentlich über XML-RPC läuft. Diese Frage ist wichtiger als die Entscheidung selbst. Die WordPress Mobile App bleibt eines der klarsten Beispiele für ein Tool, das auf XML-RPC angewiesen ist, um zu funktionieren.

Einige Dinge hängen tatsächlich davon ab:

1. Mobile Workflows , Apps, die Beiträge remote veröffentlichen, bearbeiten oder löschen, ohne das Dashboard zu berühren.
2. Jetpack-Verbindungen , Statistiken, Backups und Sicherheitsscans, die mit WordPress.com-Diensten verknüpft sind.
3. Automatisierung durch Dritte , Tools wie IFTTT oder ältere Clients, die extern posten, aktualisieren oder Aktionen auslösen.

Geh diese Liste ehrlich durch. Wenn etwas darauf zu deiner Einrichtung passt, hast du einen Grund, XML-RPC aktiv zu lassen, und einen Grund, es richtig zu schützen. Wenn nichts zutrifft, lässt du eine Tür unverschlossen für einen Raum, den niemand nutzt. Schließ sie.

Risiken der Aktivierung

`xmlrpc.php` ungeschützt offen zu lassen, liefert Angreifern einen fertigen Einstiegspunkt. Die Methode `system.multicall` ist besonders gefährlich , sie ermöglicht es, tausende Benutzername- und Passwort-Kombinationen innerhalb einer einzigen Anfrage zu testen, was Credential Stuffing von einer langwierigen Angelegenheit in etwas nahezu Mühelosen verwandelt. Tests haben gezeigt, dass ein einziger Aufruf wp.getUserBlogs tausendfach erreicht, begrenzt nur durch PHP-Speicherbeschränkungen.

Diese Schwachstelle bleibt auch nicht auf eine einzelne Website beschränkt. Über 20.000 kompromittierte WordPress-Installationen wurden in Botnetze eingegliedert, die speziell dafür eingesetzt werden, andere Server per Brute-Force anzugreifen. Der Schaden strahlt nach außen, und Ihre Website wird Teil der Angriffsinfrastruktur eines anderen, ohne dass Sie es je erfahren.

Die Pingback-Funktionalität bringt ihre eigenen Probleme mit sich. Methoden wie `pingback.ping` können missbraucht werden, um Drittziele mit Traffic zu überfluten und Ihren Server in DDoS-Aktivitäten hineinzuziehen. Derselbe Mechanismus öffnet auch einen Weg für SSRF , interne Netzwerkaufklärung durch eine Funktion, die die meisten Websites nicht aktiv nutzen oder benötigen.

Echte Kontrolle bedeutet, zu entscheiden, was aktiv bleibt und was gestrichen wird. Deaktivieren Sie, was keinem Zweck dient, schränken Sie ein, was übrig bleibt, und hören Sie auf, Angreifern kostenlose Infrastruktur zur Verfügung zu stellen.

Schritte zum Deaktivieren von XML-RPC

Bevor du irgendetwas anfasst, mach dir ein Bild davon, was noch von XML-RPC abhängt , veraltete Publishing-Tools, mobile Apps, Jetpack-Integrationen. Diese stillschweigend zu zerstören, unterläuft den ganzen Zweck der Härtung deiner Seite. Schließe also zuerst Abhängigkeiten aus und wähle dann einen Ansatz, der zu deinem Zugriffslevel passt.

Plugin-Alternativen funktionieren gut, wenn kein Serverzugriff verfügbar ist. Disable XML-RPC und Disable XML-RPC-API lassen sich beide direkt über Plugins → Installieren einrichten, und beide erledigen die Aufgabe, ohne eine Konfigurationsdatei anzufassen. Eines dieser Plugins verzeichnet über 200.000+ Installationen, ein Zeichen dafür, wie viele Seitenbetreiber sich auf diesen unkomplizierten Schalter verlassen.

Serverseitige Blockierung ist eine Stufe darüber. Das Verweigern von `xmlrpc.php` über `.htaccess` oder eine Nginx-Konfiguration erzwingt die Einschränkung vollständig außerhalb von WordPress, was bedeutet, dass sie auch dann bestehen bleibt, wenn ein Plugin-Konflikt oder ein Update eine Einstellung vorübergehend rückgängig macht.

Der hook-basierte Weg gibt dir engere Kontrolle. Das Filtern von `xmlrpc_enabled` auf false, das Entfernen von `rsd_link` und das Entfernen des `X-Pingback`-Headers schließt die weniger offensichtlichen Einstiegspunkte, die das bloße Blockieren der Datei übersieht. Füge diesen Code in ein Must-Use-Plugin ein, damit er lädt, bevor irgendetwas anderes eingreifen kann.

Ein Randfall, den man einplanen sollte: Wenn ein bestimmter Dienst wirklich XML-RPC-Zugriff benötigt, hält IP-Allowlisting diesen Kanal für vertrauenswürdige Quellen offen, während er überall sonst abgeschaltet wird. So musst du dich nicht zwischen Funktionalität und Sicherheit entscheiden , du entscheidest bewusst, wer durchgelassen wird.

Xmlrpc.Php sperren, ohne Jetpack zu beeinträchtigen

Wenige Dateien auf einem WordPress-Server ziehen so viel unerwünschten Traffic auf sich wie xmlrpc.php. Botnetze hämmern unaufhörlich darauf ein, testen Brute-Force-Schwachstellen und Pingback-Exploits, und der Instinkt, die Datei komplett zu blockieren, ist durchaus verständlich. Das Problem ist nur, dass Jetpack genau diesen Endpunkt für Sync, Statistiken und mehrere andere Funktionen nutzt, die man vermutlich nicht verlieren möchte.

Die eigentliche Lösung liegt in der selektiven Freigabe, nicht in einer pauschalen Blockade. Man sperrt den Endpunkt grundsätzlich und schafft dann gezielt Zugang für Jetpacks veröffentlichte IP-Bereiche, die direkt von jetpack.com/ips-v4.txt bezogen werden können. Diese Liste wird von Automattic gepflegt, also sollte man sie als Lesezeichen speichern und regelmäßig erneut aufrufen, statt sie als einmalige Referenz zu behandeln.

Bei Apache erfolgt das innerhalb eines ``-Blocks. Man setzt den Standard auf `Require all denied` und fügt dann für jede Adresse aus der Liste eine einzelne `Require ip`-Zeile hinzu. Nginx funktioniert etwas anders , man schreibt einen `location`-Block, der auf die Datei zielt, fügt für jede Jetpack-IP eine `allow`-Anweisung hinzu und schließt mit `deny all` ab. Bei Nginx kommt es auf die Reihenfolge an, daher müssen die allow-Zeilen zuerst stehen.

Bevor man das in die Produktivumgebung übernimmt, sollte man es in einer Staging-Umgebung testen. Prüfen Sie, ob Jetpack sich einwandfrei verbindet und ob die Dashboard-Funktionen intakt bleiben. Halten Sie außerdem einen Rollback bereit, denn eine einzige fehlkonfigurierte Regel kann die Jetpack-Verbindung unbemerkt zerstören, während die Website nach außen weiterhin normal aussieht. Bleibt ein solcher Endpunkt ungeschützt, kann er mehrere Tausend POST-Anfragen pro Tag allein von Brute-Force-Bots anziehen.

Es braucht zu Beginn etwas Geduld, um dies richtig umzusetzen. Richtig gemacht, schließt man damit jedoch eine der am häufigsten angegriffenen Türen seines Servers, ohne das Werkzeug zu opfern, das sie schützt.

Benutzeraufzählung in der REST-API blockieren

Die Routen `/wp/v2/users` und `/wp/v2/users/(?P[\d]+)` liefern jedem, der danach fragt, eine saubere, strukturierte Liste der Kontonamen Ihrer Website. Das ist kein geringfügiges Versehen , Credential Stuffing und Brute-Force-Tools sind genau dafür gebaut, diese Art von mühelosem Aufklärungsversuch auszunutzen.

Diese Endpunkte für nicht authentifizierte Anfragen einzuschränken, ist der richtige Schritt, und der `rest_endpoints`-Filter ist dafür der sauberste Weg. Anstatt einen Authentifizierungsfehler zu werfen, der bestätigt, dass die Route existiert, hält die Rückgabe eines 404 die Angriffsfläche unauffällig und gibt niemandem, der sondiert, etwas Brauchbares zurück. Plugins wie Stop User Enumeration erreichen das von Haus aus, indem sie eine Standardregel verwenden, die Endpunkte mit „users“ blockiert.

Das Absichern der nativen Benutzerrouten löst jedoch nur einen Teil des Problems. Benutzerdefinierte Endpunkte verdienen die gleiche Sorgfalt, denn ein fehlender oder zu freizügiger Permission-Callback kann dieselbe Angriffsfläche still und heimlich durch eine völlig andere Tür wieder öffnen. Jede Route, die Sie registrieren, benötigt eine bewusste Zugriffsprüfung , behandeln Sie das als unverzichtbar, nicht als Nebensache.

Einschränkung des /wp/v2/users-Endpunkts

Das Offenlassen des `/wp-json/wp/v2/users`-Endpunkts ist einer dieser stillen Fehler, die sich mit der Zeit summieren. Standardmäßig kann jeder anonyme Besucher eine vollständige Liste von Benutzer-IDs, Slugs und Anzeigenamen abrufen, ohne sich authentifizieren zu müssen. Das ist kein geringfügiges Leck , es handelt sich um genau die Art von Aufklärungsdaten, die Brute-Force-Angriffe und Credential-Stuffing-Kampagnen befeuern, noch bevor Sie den Anstieg des Datenverkehrs überhaupt bemerkt haben.

Die gute Nachricht: Diese Lücke zu schließen bedeutet nicht, Ihre REST-API komplett zu demontieren. Sie nehmen gezielte Anpassungen vor, ohne das ganze Haus abzureißen. Drei Dinge müssen passieren.

Erstens: Entfernen Sie die Routen `/wp/v2/users` und `/wp/v2/users/(?P[\d]+)` für jede Anfrage, die nicht authentifiziert ist. Diese eine Änderung unterbindet den direktesten Zugang zu Ihren Benutzerdaten. Zweitens: Erzwingen Sie Berechtigungsprüfungen , `list_users` ist hier die richtige Wahl , sodass nur Rollen mit einem echten Grund für den Zugriff auf diese Daten tatsächlich darauf zugreifen können. Drittens: Verstärken Sie dies auf Serverebene, indem Sie `/wp-json/wp/v2/users` über Ihre Apache- oder Nginx-Konfiguration blockieren. Betrachten Sie es als zusätzliches Schloss an einer Tür, die Sie bereits verriegelt haben.

Ihre Admin-Workflows laufen weiterhin ohne Unterbrechung. Authentifizierte Benutzer behalten vollen Zugriff auf das, was sie benötigen, und das Verhalten des Endpunkts, auf das sich Ihre Plugins und Themes verlassen, bleibt unverändert. Was sich ändert, ist die Angriffsfläche , und die schrumpft erheblich. Das ist der Unterschied zwischen Sicherheit, die sich einschränkend anfühlt, und Sicherheit, die einfach durchdacht gebaut ist. Es lohnt sich, sich daran zu erinnern, dass genau diese Endpunkt-Offenlegung aus einfacher Autorenarchiv-Enumeration einen vollautomatisierten, groß angelegten Benutzernamen-Sammelbetrieb für Angreifer macht, die Skripte im großen Maßstab ausführen.

Strikte Durchsetzung von Berechtigungs-Callbacks

Das Weglassen eines `permission_callback` bei einer benutzerdefinierten REST-Route ist einer der leiseren Fehler, die man in WordPress machen kann , leise, weil nichts sofort kaputtgeht, und genau diese Stille macht es so gefährlich. Bot-Traffic braucht keine Login-Aufforderung, um damit zu beginnen, Benutzer, Rollen und privilegierte Endpunkte zu kartieren. Es braucht lediglich eine offene Tür. Diese Prüfung erfolgt, bevor der Haupt-Callback überhaupt ausgeführt wird, und genau deshalb ist es so wichtig, sie richtig umzusetzen.

Jede benutzerdefinierte Route, die man registriert, braucht einen bewusst gewählten Callback, und das bedeutet, zu verstehen, was jeder Ansatz tatsächlich bewirkt.

`__return_true` mag wie ein Platzhalter wirken, den man später noch überarbeiten will, funktioniert aber genauso wie gar kein Schutz. Der einzige Ansatz, der tatsächlich funktioniert, ist die fähigkeitsbasierte Prüfung mittels `current_user_can()` gegen die minimale Fähigkeit, die eine Anfrage tatsächlich erfordert. Genau in der Unterscheidung zwischen einem eingeloggten Benutzer und einem Benutzer mit den richtigen Berechtigungen liegen die meisten Lücken in der Zugriffskontrolle.

Sensible Endpunkte verdienen diese Genauigkeit. Baue die Prüfung um das, was die Route tatsächlich tut, passe sie an die kleinste noch sinnvolle Fähigkeit an, und du hast den Aufklärungsweg geschlossen, bevor er zu einem Problem wird.

XML-RPC- und REST-API-Anfragen ratenbegrenzen

Die Drosselung von Anfragen an `xmlrpc.php` und `/wp-json/` ist eine der wirksamsten Maßnahmen, um eine WordPress-Site zu schützen , und das geschieht bevor PHP überhaupt aufwacht. Botnetze verlassen sich auf unbegrenzte Authentifizierungsversuche und Pingback-Missbrauch, und sie am Nginx– oder WAF-Level abzuschneiden, entzieht ihnen den Ansatzpunkt, den sie benötigen. Kein Plugin-Overhead, keine Serverlast. Nur saubere Durchsetzung am Rand.

XML-RPC verdient Ihre strengsten Grenzwerte. Legitimer Datenverkehr über diesen Endpunkt ist heutzutage tatsächlich selten, daher ist eine Obergrenze von wenigen Anfragen pro Minute durchaus angemessen. Tatsächlich setzen viele WordPress-Umgebungen einen globalen Schwellenwert von nur zehn Anfragen pro 30 Sekunden für diesen Endpunkt durch, wobei auffällige IPs eine einstündige Sperrung erhalten. Die meisten echten Nutzer werden das nie bemerken, und alles, was diesen Pfad massenhaft bombardiert, hat mit ziemlicher Sicherheit nichts Gutes im Sinn.

Die REST-API erfordert einen differenzierteren Ansatz. Lesezugriffe können sich großzügige Schwellenwerte leisten , Suchmaschinen und legitime Clients sind auf sie angewiesen. Schreibzugriffe und alles, was Benutzerdaten betrifft, sollte streng gedrosselt werden, denn genau das sind die Pfade, die Angreifer testen, wenn sie Zugangsdaten prüfen oder Inhalte einschleusen.

Ein Token-Bucket-Modell bewältigt Burst-Traffic elegant. Anstatt einen echten Nutzer abzuschneiden, der für ein paar Sekunden einen Aktivitätsschub erlebt, fängt adaptive Drosselung diesen kurzfristigen Anstieg ab und erholt sich schnell. Das Ziel ist es, anhaltenden Missbrauch zu stoppen, nicht jemanden zu bestrafen, der während eines Produktlaunches eine Seite aktualisiert.

Wenn eine Anfrage den Schwellenwert überschreitet, erhält sie eine `429`-Antwort und nichts weiter. Ihr Ursprungsserver bleibt geschützt, Ihre echten Besucher bleiben unbeeinträchtigt, und automatisierter Missbrauch stößt an eine Wand , sauber, effizient und ohne Ressourcen zu verbrauchen, die Sie lieber anderswo einsetzen würden.

Überwachen Sie Ihre Logs auf XML-RPC-Botnet-Probing

Ihre Logs erledigen die harte Arbeit , Sie müssen nur lernen, sie zu lesen.

Beginnen Sie mit den offensichtlichen Signalen. Wiederholte POST-Anfragen, die unaufhörlich auf xmlrpc.php einprasseln, Wellen von unterschiedlichen IP-Adressen, die denselben Endpunkt ansteuern, Datenverkehr, der in diesem unverkennbaren robotischen Takt eintrifft, den kein menschlicher Administrator je erzeugen würde , das ist kein Rauschen, das ist ein Muster mit einer Botschaft.

Statuscodes können Sie in die Irre führen, wenn Sie es zulassen. Eine lückenlose Reihe von 200ern wirkt beruhigend, sagt aber nichts darüber aus, was diese Anfragen tatsächlich enthielten. Graben Sie sich, wenn möglich, in die Payload-Signaturen ein. System.multicall und wp.getUsersBlogs sind die Erkennungsmerkmale von Credential-Stuffing-Operationen, und sie frühzeitig zu entdecken macht den Unterschied zwischen dem Erkennen eines Problems und dem nachträglichen Aufräumen.

Vergleichen Sie Ihren xmlrpc.php-Traffic mit der Aktivität von wp-login.php. Wenn der eine stark ansteigt, während der andere flach bleibt, ist diese Asymmetrie kein Zufall , jemand testet, wie weit er durch eine Seitentür kommt, die Sie zu beobachten vergessen haben. Dieser Vergleich kostet Sie nichts und verrät Ihnen alles.

Wenn die Zugriffsprotokolle nicht genug Detail liefern, gehen Sie tiefer. Ziehen Sie Ihre WAF-Aufzeichnungen oder paketbasierte Daten heran. Mit jeder zusätzlichen Ebene wird das Bild klarer.

Online-Sicherheit ist keine passive Angelegenheit. Botnetze sind geduldig und methodisch, und sie zielen gezielt auf Websites, deren Besitzer aufgehört haben, aufzupassen. Wenn Sie nicht auf veraltete mobile Apps oder Jetpack-Plugins angewiesen sind, entfernt das Deaktivieren von XML-RPC gänzlich die Tür, die sie überhaupt erst abklopfen. Weiter beobachten, weiter vergleichen, weiter graben , diese Gewohnheit ist es, die Sie wirklich schützt.