Was ein stillgelegtes WordPress an Angriffen anzieht

Über Sicherheit von Content-Management-Systemen wird viel behauptet und wenig gezählt. Als ich zwei alte WordPress-Auftritte durch statische Seiten ersetzt habe, lagen die Server-Logs von vorher und nachher vor. Also habe ich nachgesehen, statt zu vermuten.

Es geht um mageconsult.de und magelounge.de, zwei Domains aus meiner Magento-Zeit. mageconsult war ab 2010 mein erster Auftritt als Freelancer, magelounge der dazugehörige Blog mit Fachbeiträgen aus derselben Zeit. Beide waren seit Jahren inhaltlich eingefroren: keine neuen Beiträge, keine Nutzer, keine Kommentare. Sie liefen einfach weiter.

Heute stehen dort statische Seiten, die beiden Links oben führen direkt darauf.

Die Zahlen

Gezählt habe ich Anfragen auf die typischen WordPress-Ziele, also wp-login.php, wp-admin und xmlrpc.php, über 27 Tage vom 14. Juli bis zum 9. August 2026.

Entscheidend ist dabei ein Detail der Methode: Es zählt nur der tatsächlich angefragte Pfad. Sucht man den Begriff stattdessen in der ganzen Log-Zeile, findet man ihn auch im Referrer und im User-Agent. Mein erster Zählversuch kam so auf fast das Doppelte, bevor mir auffiel, woher die Differenz stammte. Der Auswertung liegt deshalb ein awk-Aufruf zugrunde, der sich nur das Request-Feld vornimmt und dessen Statuscode ausliest, nicht ein einfaches grep über die Datei.

Das sind im Schnitt rund 1.960 Anfragen pro Tag auf zwei Seiten, die niemand mehr pflegte.

Die zweite Spalte ist die wichtige

Dass Bots WordPress-Pfade durchprobieren, ist bekannt und für sich genommen harmlos. Interessant ist die zweite Spalte: 34.142 dieser Anfragen wurden mit Status 200 beantwortet. Jedes Mal hat der Server ein funktionierendes Login-Formular ausgeliefert. Nicht kompromittiert, wohlgemerkt, aber angeboten.

Genau das ist der Unterschied zwischen Angriffsfläche und Angriff. Solange ein Login-Formular antwortet, hängt die Sicherheit an der Qualität des Passworts, an der Aktualität von Kern und Plugins und daran, dass keine Lücke bekannt wird, bevor man das nächste Update einspielt. Bei einer Seite, die man aktiv betreibt, ist das eine Routine. Bei einer, die man seit Jahren nicht angefasst hat, ist es eine offene Wette.

Das ist auch die Grenze, an die der Probe-Block in der .htaccess stößt, den ich im Frühjahr eingerichtet hatte. Er fängt Scanner-Pfade wie .env oder vendor/ mit einem 410er ab, aber wp-login.php muss offen bleiben, solange WordPress läuft. Der Lärm war weg, die Tür blieb.

Bemerkenswert ist auch die Verteilung über die Zeit: Der stärkste Tag auf magelounge war ausgerechnet der 9. August, der Tag der Ablösung, mit 5.743 Anfragen und 3.475 Antworten. Am Vortag waren es 3.252. Die Belastung war am Ende am höchsten, nicht am Anfang.

Die Ausschläge nach oben sind einzelne Scanner, die eine Domain für ein paar Stunden systematisch durchgehen. Zwischendurch liegen ruhige Tage mit unter 200 Anfragen. Ein Muster im Sinne von „wird immer schlimmer" gibt es nicht, es ist Grundrauschen mit Wellen.

Nach der Umstellung

Seit dem 10. August liefern beide Domains nur noch vorbereitete Dateien aus. Kein PHP im Auslieferungsverzeichnis, keine Datenbank, kein Login.

Die Zahl der Anfragen ist deutlich gefallen, und dieser Teil ist mit Vorsicht zu lesen: Fünf Tage sind ein kurzer Zeitraum, und ein Teil des Rückgangs dürfte schlicht daran liegen, dass Scanner ihre Ziellisten noch nicht aktualisiert haben. Erfahrungsgemäß nimmt das weiter ab, wenn eine Adresse dauerhaft nichts mehr hergibt.

Ich behalte die Logs im Auge und aktualisiere die Zahlen hier bei Gelegenheit. Nach ein paar Monaten lässt sich deutlich besser sagen, ob die Kurve wirklich flach bleibt oder ob die Scanner einfach nur eine Weile brauchen.

Die zweite Spalte ist dagegen keine Frage der Zeit. Sie ist strukturell null, weil es nichts mehr gibt, das antworten könnte. Die Anfragen laufen ins Leere, und wer gezielt nach WordPress-Pfaden fragt, bekommt einen 410er, der zugleich die Sperrliste des Servers füttert.

Was das nicht heißt

Es heißt nicht, dass WordPress unsicher ist. Ein gepflegtes WordPress mit aktuellen Updates, schlanker Plugin-Liste und Zwei-Faktor-Anmeldung ist ein solides System, und für Seiten, an denen regelmäßig mehrere Leute arbeiten, gibt es gute Gründe dafür.

Es heißt, dass ein ungepflegtes WordPress teurer ist, als es aussieht. Die Kosten stehen nicht auf der Rechnung, sondern in der Wahrscheinlichkeit, dass irgendwann eine Lücke bekannt wird, bevor man das Update einspielt. Bei zwei Seiten, die inhaltlich fertig sind und nur noch als Archiv existieren, ist diese Wette überflüssig.

Die Frage dahinter: Wofür läuft die Seite noch?

Der Auslöser war bei mir nicht die Sicherheit, sondern eine Aufräum-Frage: Wofür läuft das eigentlich noch? mageconsult und magelounge stammen aus einer abgeschlossenen Zeit. Aus mageconsult wurde CommerceWerft und daraus com:werft, wo ich heute als Freelancer für Shopware 6, Laravel und PHP arbeite. Die alten Domains sollten bleiben, sie tragen Beiträge, auf die noch verlinkt wird, und die Chronik einer Marke. Nur brauchten sie dafür kein Content-Management-System mehr.

Genau das ist die Entscheidung, die hinter den Zahlen oben steht. Eine Seite, die sich nicht mehr ändert, braucht keine Datenbank und kein Login. Sobald man das anerkennt, verschwindet die Angriffsfläche als Nebenwirkung, ohne dass man sie gesondert absichern müsste.

Bei Seiten, die weiterlaufen sollen, ist die Antwort natürlich eine andere. Dort führt der Weg über Updates, eine schlanke Plugin-Liste und einen Probe-Block mit HTTP-Status-Code 410, der wenigstens den Lärm abstellt.

Wie die Umstellung selbst ablief, habe ich hier beschrieben: Zwei WordPress-Seiten an einem Nachmittag abgelöst.