Ein WordPress-Security-Plugin, das aus echten Angriffen entstanden ist
Weil ein Wochenende mit Access-Logs manchmal mehr lehrt als jeder Sicherheitskurs.
Von Oliver Meyer – WordPress-Spezialist aus Bremen, seit 2010
Manchmal beginnen die wichtigsten Dinge damit, dass etwas nicht stimmt. Ein IONOS-Fehler, den ich so noch nie gesehen hatte. Eine Fehlermeldung, die sich nicht einordnen ließ. Und dann: Serverlogdateien, die zeigten, was wirklich passierte.
Genau da fing alles an.
Was in den Logs stand
Ich hatte keine großen Erwartungen, als ich die Access-Logs zum ersten Mal öffnete. Aber was ich fand, war eindeutig: Hunderte von Anfragen auf xmlrpc.php, immer wieder dieselben IP-Adressen, dasselbe stupide Muster. Bots, die nicht aufhören. Angreifer, die sich keine Mühe geben, weil sie es nicht müssen – weil die meisten WordPress-Installationen einfach antworten.
Die Webseite unter aber-sicher-bremen.de war betroffen. Nicht dramatisch, WordPress nicht gehackt – aber ausgebremst, belastet, unnötig beschäftigt. Das wollte ich ändern. Nicht mit einem Fertigplugin, das ich blind installiere. Sondern mit einem Verständnis für das, was dahintersteckt.
Ein Plugin, das aus dem Problem heraus entstanden ist
Was dann folgte, war ein Wochenende mit echten Logs, echten Entscheidungen und sehr viel Kaffee. Das Ergebnis: ein eigenes WordPress-Security-Plugin, entwickelt auf Basis der tatsächlichen Angriffsmuster meiner eigenen Seite.
Der Unterschied zu fertigen Security-Plugins am Markt liegt nicht in der Technik allein. Er liegt im Ursprung. Dieses Plugin ist nicht aus einem Produktkatalog entstanden. Es entstand aus konkreten Fragen: Was genau passiert hier? Welche Antwort ist die richtige – nicht die pauschalste? Was bringt wirklich etwas, und was ist nur Lärm?
Das ist der stille innere Antrieb, der sich kaum erklären lässt – aber genau der richtige ist.
Was das Plugin konkret macht
xmlrpc.php blockieren – mit minimalem Response-Overhead
Alle Anfragen auf xmlrpc.php werden abgeblockt – mit einer Antwort, die nur 2 Bytes zurücksendet: ein schlichtes no. Das klingt klein, ist aber eine Reduktion des Response-Overheads um über 99 %. Der Server hat weniger zu tun, die Bots bekommen nichts Verwertbares.
Analyse echter Angriffsmuster
Statt auf Vermutungen zu reagieren, wurde das Plugin auf Basis der tatsächlichen Access-Logs kalibriert. Welche IPs greifen wiederholt an? Welche Pfade werden sondiert? Welche Reaktion ist wirkungsvoll – und welche unnötig teuer? Diese Fragen stellte ich mir, bevor auch nur eine Zeile Code geschrieben wurde.
.htaccess als erste Verteidigungslinie
Sicherheit beginnt auf Serverebene, nicht im WordPress-Code. Bestimmte Zugriffe werden bereits in der .htaccess abgefangen – bevor WordPress überhaupt geladen wird. Das spart Ressourcen und macht die Abwehr robuster.
Kein unnötiger Ballast
Viele Security-Plugins bringen Features mit, die Vertrauen signalisieren sollen – aber selbst Last erzeugen. Dieses Plugin macht das Gegenteil: nur das, was wirklich hilft. Nichts mehr.
Was ich dabei gelernt habe – und was das für Ihre Seite bedeutet
15 Jahre WordPress-Erfahrung plus echte Angriffsdaten ergibt etwas anderes als ein fertiges Plugin aus dem Repository. Es ergibt ein Verständnis, das sich nicht kaufen lässt: für das Warum hinter den Maßnahmen, für die Wirkung jeder einzelnen Entscheidung.
Inzwischen profitieren mehrere Bremer WordPress-Seiten von diesem Ansatz – nicht weil das Plugin das lauteste ist, sondern weil es aus dem richtigen Ort kommt. Aus einem echten Problem, das ehrlich gelöst wurde.
Denn das ist der Unterschied zwischen einer Sicherheitslösung, die irgendjemand zusammengeklickt hat – und einer, bei der jemand die Logs gelesen hat.
Interesse?
Wenn Sie wissen möchten, was in den Logs Ihrer WordPress-Seite steht – und was man dagegen tun kann – sprechen Sie mich an. Ich schaue mir Ihre Situation an und sage Ihnen ehrlich, was sinnvoll ist.