Wie mache ich einen Sicherheitscheck, was meine WordPress-Website preisgibt?

Warum das wichtig ist

Die meisten Sicherheitstipps drehen sich um Schalter: das hier einschalten, das da deaktivieren. Aber ein Schalter sagt dir, was du verlangt hast, nicht, was passiert ist. Eine Caching-Ebene liefert vielleicht eine alte Antwort aus. Eine CDN-Regel blockiert eine Datei womöglich, bevor WordPress die Anfrage überhaupt sieht. Ein Plugin öffnet vielleicht wieder, was ein anderes geschlossen hat. Die einzig ehrliche Antwort auf „Was gibt meine Website preis?“ bekommst du, wenn du sie so fragst, wie es ein Fremder tun würde – mit einem Sicherheitscheck von außen.

Die gute Nachricht: Die Liste dessen, was sich auf der Login-Seite zu prüfen lohnt, ist kurz. Bots suchen auf jeder WordPress-Website nach denselben paar Adressen:

Keine davon ist für sich allein eine Katastrophe. Zusammen liefern sie einem Bot eine Liste von Namen und zwei Türen, an denen er sie ausprobieren kann. Wenn du weißt, welche offen sind, kannst du sie in der richtigen Reihenfolge schließen: zuerst die Türen, dann die Namen.

Häufige Fehler

• Im angemeldeten Zustand testen. WordPress zeigt angemeldeten Benutzern mehr. Nutze ein privates Fenster oder curl.
• Die gecachte Seite testen. Hast du gerade eine Einstellung geändert, leere zuerst deinen Seiten-Cache und CDN-Cache, sonst siehst du die alte Antwort.
• Beim ersten grünen Licht aufhören. Das Login-Formular zu schließen, während XML-RPC offen bleibt, ist die häufigste halbe Lösung, die wir sehen.
• Ein vollständiges Sicherheitsaudit erwarten. Diese Checks drehen sich um die Zugänge. Über Malware, Dateiänderungen oder veraltete Plugins sagen sie nichts.

Ohne Plugin

Die fünf curl-Befehle aus Schritt 1 sind die manuelle Methode, und es lohnt sich, sie zu kennen. Lies die Ergebnisse so:

• HTTP/2 200 bei wp-login.php: Der Standard-Login ist öffentlich. 404: Er ist versteckt.
• XML-RPC server accepts POST requests only. von xmlrpc.php: Der Endpunkt ist aktiv. Um zu sehen, ob ein Login angenommen wird, müsstest du einen wp.getUsersBlogs-Aufruf mit einem Testkonto senden.
• Ein JSON-Array von /wp/v2/users mit "slug"-Feldern: Benutzernamen sind öffentlich. 401 oder ein leeres Array: geschlossen.
• Location: /author/name/ von ?author=1: ein Leck. Wiederhole es mit 2, 3 und so weiter, um zu sehen, wie viele Benutzer ein Bot einsammeln könnte.
• 200 bei der Benutzer-Sitemap: Autoren-URLs werden aufgelistet.

Der Nachteil ist der Aufwand an Zeit und Deutung. Du musst es nach jeder Änderung wiederholen, und um den XML-RPC-Login richtig zu testen, musst du XML von Hand zusammenbauen.

Wenn etwas schiefgeht

• Der Scan meldet „offen“, obwohl du es ausgeschaltet hast. Leere Seiten- und CDN-Cache und scanne erneut. Ist es weiterhin offen, setzt womöglich ein anderes Plugin oder eine Serverregel die Einstellung außer Kraft.
• Der Scan erreicht deine Website nicht. Manche Hoster hindern eine Website daran, Anfragen an sich selbst zu senden (Loopback). Bitte deinen Hoster, Loopback-Anfragen zu erlauben, oder nutze die curl-Methode von außen.
• Nach der Härtung sickert weiterhin ein Benutzername durch. Prüfe die Autorenbox deines Themes und die Autoren-Sitemap deines SEO-Plugins. Ändere den öffentlichen Namen des Autors, wenn das Theme ihn ausgibt.

Mit Hushfort

Der Angriffsflächen-Scan sitzt im Bereich Angriffsflächen-Härtung von Hushfort Security, dem kostenlosen WordPress-Sicherheitsplugin. Er misst mit echten Anfragen, was deine Website tatsächlich preisgibt – genau wie die manuelle Methode – und nennt die gefundenen Benutzernamen beim Namen. Jeder Befund gehört zu einer Hushfort-Ebene, die ihn schließt:

• XML-RPC-Login → Hintertür-Sperre (Pro)
• REST-Benutzerliste, Autoren-Scans, Sitemap → Benutzernamen-Schutz (Pro)
• Standard-Login → Login verstecken (kostenlos)

Wir haben den Angriffsflächen-Scan gebaut, nachdem ein Shop weiterhin Passwortversuche über XML-RPC erhielt, obwohl seine Login-Seite versteckt war. Die Einstellung sah gut aus; erst eine echte Anfrage zeigte die offene Tür.