Als ich Ende Juli meinen gehackten Blog auseinandergenommen habe, gab es einen Moment, der mir bis heute nachgeht. Ich habe in der Datenbank nachgesehen, welche Plugins aktiv sind. Es war genau eines. Es hieß wp2p_bdde96d5, und es war nicht von mir.
Heute sieht dieselbe Abfrage so aus:
array (
)Leer. Kein einziges aktives Plugin. Das ist keine Marketing-Formulierung, das ist der Inhalt des Datenbankfeldes.
Was passiert war
Aufgefallen ist der Einbruch durch einen abgebrochenen Automatisierungs-Ablauf: Anmeldung fehlgeschlagen. Jemand hatte sämtliche Anwendungspasswörter aller Benutzer gelöscht.
Der erste fremde Administrator war neun Tage vorher angelegt worden. Neun Tage, in denen ich täglich auf der Seite war und nichts bemerkt habe. Insgesamt waren es fünf fremde Konten, zwei davon ohne E-Mail-Adresse — die lassen sich über die Oberfläche gar nicht anlegen.
Die Software saß auf vier Ebenen gleichzeitig:
- sieben Lader im
mu-plugins-Ordner, getarnt als „WP Core Update Helper”, mit auf Dezember zurückdatierten Dateidaten - über zehn Nutzlasten im Upload-Verzeichnis, benannt wie WordPress-Kernklassen
- fünfzehn Laufzeitkopien in
/tmp, jede exakt 93.952 Bytes groß - ein 125 KB großer Eintrag in der Datenbank, getarnt als zwischengespeicherter Systemstatus
Zweck war Suchmaschinen-Betrug: Google bekam andere Inhalte serviert als menschliche Besucher. In einer Markierungsdatei stand das Wort chinafans.
Das Unangenehmste kam beim Aufräumen. Während ich mitten in der Analyse saß, hat sich die Markierungsdatei neu geschrieben. Das Ding lief noch, während ich es suchte.
Über vierzig Schaddateien in zwei Runden. Wie er reingekommen ist, weiß ich bis heute nicht — die Zugriffsprotokolle reichen sieben Tage zurück, der entscheidende Tag war schon rausrotiert.
Der Neuanfang
Ich habe die Installation nicht gesäubert. Ich habe sie neu gebaut.
Neuer Systembenutzer, eigene Datenbank, eigener PHP-Prozess. Übernommen wurden nur Inhalte: 197 Beiträge, 25 Entwürfe, sechs Seiten, 367 von 371 Mediendateien — die fehlenden vier waren SVG-Dateien, und die habe ich absichtlich draußen gelassen. SVG ist XML, XML kann Skripte enthalten.
Was danach übrig blieb, lässt sich in einer Zahl sagen: von rund 9.200 PHP-Dateien auf knapp 1.475. Vierundachtzig Prozent weniger Code, den jemand angreifen kann.
Das ging so leicht, weil die Ausgangslage günstig war. Ich hatte schon ein eigenes Theme mit fünfzehn Dateien. Und ich hatte, wie sich zeigte, null legitim aktive Plugins — der einzige Eintrag war ja die Hintertür.
Was jetzt an der Stelle der Plugins steht
Neun eigene Dateien, jede mit einer klaren Aufgabe:
| Datei | ersetzt |
|---|---|
00-hardening.php |
Sicherheits-Plugin |
10-local-avatars.php |
Avatar-Plugin |
20-no-comments.php |
Spamschutz |
30-seo-meta.php |
SEO-Plugin |
40-redirects.php |
Weiterleitungs-Plugin |
50-indexnow.php |
IndexNow-Plugin |
60-startseite.php |
Startseiten-Steuerung |
70-ui-fixes.php |
Bedien- und Zugänglichkeitskorrekturen |
80-archiv-hygiene.php |
Sitemap- und Feed-Kontrolle |
Und jetzt der Teil, den ich beim Schreiben selbst nachgerechnet habe, weil ich ihn erst nicht glauben wollte: Das alles zusammen hat keine Stunde gedauert. Nicht weil ich so schnell PHP schreibe, sondern weil ich es nicht selbst geschrieben habe. Ich habe beschrieben, was passieren soll, und gegengelesen, was dabei herauskam.
Seitdem läuft es. Ohne Update-Meldungen, ohne Kompatibilitätsprobleme, ohne dass mir jemand ein Premium-Angebot ins Backend legt.
Die Seite ist nebenbei schnell geworden: erster sichtbarer Inhalt nach 244 Millisekunden. Und beim Bilder-Aufräumen kamen 375 MB zusammen, die niemand gebraucht hat — das größte Bild auf der Startseite schrumpfte von 526 auf 41 Kilobyte.
Der ehrliche Teil
Erstens: Das Backend ist nicht mehr der Ort, an dem ich arbeite
Wenn mich jemand fragt, welches Plugin ich vermisse, ist die ehrliche Antwort: keins. Aber das liegt nicht daran, dass ich so genügsam wäre. Es liegt daran, dass ich den Blog gar nicht mehr über die Oberfläche bediene.
Ich schreibe in meinen Notizen. Von dort geht es weiter. Und wenn ich unterwegs eine Idee habe, schicke ich sie meinem Server per Telegram.
Der Ersatz für die Plugins ist also kein Code. Es ist ein anderer Arbeitsweg. Wer weiterhin im Backend klickt, wird die Plugins sehr wohl vermissen — und sollte sie behalten.
Zweitens: Weniger Code hätte den nächsten Angriff nicht verhindert
Mitte August kam eine Sicherheitslücke heraus, die im Kern von WordPress saß. Verkettet mit einer zweiten reichte sie aus, um ohne Anmeldung eine dauerhafte Hintertür abzulegen.
Gegen so etwas hilft „ich habe keine Plugins” exakt gar nichts. Mein Blog war nur zufällig schon auf einer Version, die den Fehler nicht hatte.
Wer aus diesem Artikel mitnimmt, dass wenig Code gleich sicher bedeutet, hat ihn falsch gelesen. Weniger Code heißt: weniger Türen. Es heißt nicht: keine Türen.
Drittens: Auch mein aufgeräumter Blog hatte drei Wochen lang Leichen im Keller
Beim Schreiben dieses Artikels habe ich die Installation noch einmal komplett durchgeprüft. Dabei fielen 23 Dateien auf, die dort nichts zu suchen hatten. Kein Angriff — Kopierreste meiner eigenen Migration.
Das Muster war eindeutig: Jeder abgeschnittene Pfad war exakt 133 Zeichen lang. Irgendein Werkzeug in meiner Kopierkette schneidet bei 133 Zeichen ab und sagt nichts.
Drei Wochen lagen die da. Nichts ging kaputt, deshalb hat es niemand gemerkt. Genau das macht solche Reste gefährlich: Sie erzeugen Rauschen in der Prüfung, und in Rauschen übersieht man echte Funde.
Ein ähnlicher Fall vorher: Beim Plugin-Rauswurf flog auch die Bildkonvertierung mit raus. Die Server-Regel dafür blieb stehen und lief wochenlang ins Leere — sauber, ohne Fehlermeldung, weil der Server brav auf das Originalbild zurückfiel. Kein Fehler, kein Log, kein kaputtes Bild. Die Seite war nur zehnmal so schwer wie nötig.
Ein stiller Rückfall ist schlimmer als ein Fehler. Ein Fehler wird repariert. Ein stiller Rückfall wird Gewohnheit.
Würde ich das empfehlen?
Ja — aber nicht jedem, und ich sage das ausdrücklich als Privatperson und nicht als jemand, der dir das verkaufen will.
Wenn du technikaffin bist oder ohnehin mit KI arbeitest: unbedingt. Der Aufwand ist heute ein Bruchteil dessen, was er vor zwei Jahren gewesen wäre, und du verstehst hinterher deine eigene Seite.
Wenn du nur bloggen willst und PHP für einen Automobilzulieferer hältst: lass die Plugins drin, halte sie aktuell, und nimm weniger davon. Ein gepflegtes Plugin ist besser als eine selbstgebaute Datei, die niemand mehr anfasst, wenn du keine Zeit hast.
Der Satz, der für mich am Ende übrig bleibt, ist ein anderer als „keine Plugins”. Er lautet: kein fremder Code, den ich nicht gelesen habe. Dass daraus bei mir null Plugins wurden, ist das Ergebnis, nicht das Ziel.
