WordPress-Hardening: Warum der Webserver seinen eigenen Code nicht ändern sollte

1. WordPress-Sicherheit: Welche Rechte braucht die Anwendung?

Ein erfolgreicher Angriff muss nicht mit einer sichtbar veränderten Startseite enden. Bleibt ein unberechtigter Zugang bestehen, können entfernte Dateien erneut angelegt werden. Eine Hintertür kann in zusätzlichem Code stecken; auffällige Änderungen können aber auch Benutzerkonten, Einstellungen oder geplante Aufgaben betreffen. Ein unverdächtiger Dateiname beantwortet diese Fragen nicht.

Deshalb interessiert mich bei der technischen Betreuung neben dem Softwarestand auch die Berechtigung des Prozesses, der WordPress ausführt. Darf er nur die notwendigen Betriebsdaten schreiben? Oder kann er zusätzlich Themes, Plugins und WordPress selbst ersetzen?

PHP muss Code lesen können – nicht grundsätzlich überschreiben

WordPress wird auf dem Server durch PHP ausgeführt. Je nach Hosting läuft PHP unter einem eigenen Benutzer pro Website oder unter einem gemeinsam verwendeten Konto. www-data ist ein mögliches Beispiel, aber keine allgemeine WordPress-Vorgabe. Auch besitzen nicht alle Installationen dieselben Schreibrechte.

Wenn PHP die Programmdateien verändern darf, sind Updates über das Dashboard bequem möglich. Diese Berechtigung steht jedoch auch ausgenutztem Code zur Verfügung, der im selben Prozess läuft. Die offizielle WordPress-Dokumentation empfiehlt deshalb, Dateirechte möglichst eng zu setzen und Schreibzugriffe gezielt zu erlauben. [1]

Ein Sicherheits-Plugin kann wichtige Aufgaben übernehmen, etwa Anmeldungen zusätzlich absichern oder Veränderungen melden. Die Trennung der Systemrechte ist eine weitere Schutzebene: Sie begrenzt, was der laufende PHP-Prozess überhaupt verändern kann. Beide Maßnahmen können sich sinnvoll ergänzen.

2. Read-only-Code: Schreiben nur über einen kontrollierten Wartungsweg

Das Grundprinzip ist überschaubar: WordPress, Plugins und Themes bleiben für den normalen PHP-Prozess lesbar, sind für ihn aber nicht beschreibbar. Benötigte Schreibbereiche werden separat festgelegt. Neue Software gelangt über einen eigenen Wartungs- oder Bereitstellungsprozess auf das System.

Entscheidend sind dabei nicht nur die Berechtigungszahlen einzelner Dateien. Auch Eigentümer, Gruppen und die Rechte der übergeordneten Verzeichnisse zählen. Kann ein Prozess eine geschützte Datei über ein beschreibbares Verzeichnis löschen und ersetzen, ist der gewünschte Schutz nicht erreicht. Gehören ihm die Dateien selbst, kann er je nach Umgebung ihre Rechte wieder ändern. [2]

Was ich unter einem Lock-System verstehe

Mit „Lock-System“ meine ich hier einen geregelten Wechsel zwischen Normalbetrieb und autorisierter Wartung. Es ist eine Beschreibung des Betriebsablaufs, kein offizieller WordPress-Sicherheitsstandard.

Für dieses Konzept bevorzuge ich einen separaten Wartungsbenutzer, der geprüften Code bereitstellt. Damit muss der öffentliche PHP-Prozess auch während eines Updates keine zusätzlichen Schreibrechte erhalten. Falls eine Installation tatsächlich kurzzeitig entsperrt werden muss, braucht dieser Zustand eine klare Begrenzung und eine zuverlässige Rückkehr zum geschützten Betrieb – auch nach einem Fehler.

Ein Schalter im Dashboard, mit dem derselbe PHP-Prozess seine eigene Sperre aufheben kann, wäre keine belastbare Trennung. Wartungszugänge und deren Zugangsdaten dürfen für diesen Prozess nicht verfügbar sein. Ebenso gehört zur Abnahme eine Prüfung der tatsächlichen Rechte; eine Statusanzeige allein genügt nicht.

Was der Schreibschutz verhindert – und was offenbleibt

Ist die Trennung korrekt umgesetzt, kann ein Angriff mit den Rechten des normalen PHP-Prozesses keine Dateien in den geschützten Codebereichen verändern oder ergänzen. Das erschwert eine wichtige Form der dauerhaften Verankerung.

Eine unbekannte Sicherheitslücke wird dadurch aber nicht geschlossen. Je nach Lücke können weiterhin Daten ausgelesen, Datenbankeinträge verändert oder vorhandene Funktionen missbraucht werden. Schreibbare Bereiche bleiben ebenfalls relevant. Übernimmt ein Angreifer einen höher berechtigten Wartungszugang oder den Server selbst, kann er auch diese Schutzgrenze überwinden.

Schreibschutz ersetzt deshalb weder Updates noch die Untersuchung eines bereits kompromittierten Systems. Vorhandenen Schadcode einzufrieren würde ihn lediglich vor Änderungen schützen.

Kann die Redaktion weiterarbeiten?

Das Ziel ist, den Redaktionsalltag beizubehalten: Texte bearbeiten, Beiträge veröffentlichen und Bilder hochladen. Inhalte liegen überwiegend in der Datenbank; Medien erhalten ihren eigenen beschreibbaren Bereich.

Eine pauschale Zusage ohne Prüfung wäre trotzdem unangebracht. Manche Erweiterungen erzeugen CSS-Dateien, Vorschaubilder, Exporte oder Caches. Vor der Umstellung müssen diese Schreibvorgänge erfasst und gezielt berücksichtigt werden. Anschließend werden die tatsächlichen Arbeitsabläufe mit den zuständigen Personen getestet. Änderungen am Programmcode und die Installation neuer Erweiterungen gehören danach zur technischen Wartung.

3. Uploads erlauben, direkte Skriptausführung verhindern

Ein Upload-Bereich muss Dateien entgegennehmen können. Daraus darf nicht automatisch folgen, dass hochgeladene Dateien über eine Webanfrage als serverseitiger Code ausgeführt werden. OWASP empfiehlt unter anderem begrenzte Dateitypen, Inhaltsprüfungen, passende Berechtigungen und nach Möglichkeit eine Speicherung außerhalb des öffentlich erreichbaren Webbereichs. [3]

Für öffentlich ausgelieferte WordPress-Medien bedeutet das: In den dafür vorgesehenen Verzeichnissen sollen passende Webserver-Regeln die direkte Ausführung von Skripten unterbinden. Welche Regeln nötig sind, hängt von Webserver und PHP-Anbindung ab. Eine bloße Prüfung auf eine einzelne Dateiendung ist keine vollständige Absicherung. Die Regeln selbst dürfen vom normalen PHP-Prozess nicht überschrieben werden können.

HTTP-Aufruf und internes Einbinden sind verschiedene Vorgänge

Eine Webserver-Regel entscheidet, wie eine eingehende HTTP-Anfrage behandelt wird. Wenn PHP dagegen eine lokale Datei mit include einbindet, läuft dieser Zugriff über das Dateisystem. Eine Sperre für direkte Webaufrufe verhindert ein solches Einbinden nicht automatisch. [4]

Diese Unterscheidung hilft bei der Fehlersuche: Eine pauschale Zugriffssperre kann benötigte Webanfragen einer Erweiterung blockieren. Umgekehrt ist eine Datei nicht automatisch ungefährlich, nur weil sie nicht direkt im Browser aufgerufen werden kann. Ein unsicherer interner Include könnte ihren Inhalt weiterhin ausführen.

Deshalb muss jede Ausnahme einen nachvollziehbaren Zweck haben. Erzeugt eine Erweiterung ausführbaren Cache-Code, braucht sie eine gesonderte Bewertung; eine allgemeine Freigabe des Upload-Bereichs wäre dafür zu weitreichend. Medien, temporäre Daten und ausführbarer Anwendungscode sollten so weit wie möglich getrennt behandelt werden.

4. Schreibschutz braucht einen verlässlichen Update-Prozess

Automatische Updates sind nicht grundsätzlich ein Stabilitätsproblem. Sie können Sicherheitskorrekturen zeitnah auf eine Website bringen. Schwierigkeiten entstehen unter anderem, wenn ein Update Schreibrechte benötigt, die das Betriebskonzept bewusst nicht vorsieht. WordPress nennt Dateiberechtigungen ausdrücklich als mögliche Ursache fehlgeschlagener Aktualisierungen. [5]

Wer den Code schützt, muss deshalb auch den Update-Weg festlegen. Hintergrund-Updates einfach abzuschalten und auf die nächste freie Stunde zu hoffen, wäre keine Verbesserung.

Für eine betreute Installation würde ich folgenden Ablauf vorsehen:

1. Änderung einordnen: Was wird aktualisiert, welche Funktionen sind betroffen und wie dringend ist eine Sicherheitskorrektur?
2. Wiederherstellung vorbereiten: Verwendbare Sicherungen und einen passenden Rückweg bereitstellen. Bei Datenbankänderungen reicht ein Austausch alter Programmdateien möglicherweise nicht aus.
3. Prüfen und bereitstellen: Änderungen möglichst in einer Testumgebung prüfen und über den autorisierten Wartungsweg einspielen.
4. Betrieb kontrollieren: Anmeldung, Redaktion, Formulare und geschäftskritische Abläufe testen. Auch Schnittstellen und geplante Aufgaben einbeziehen.
5. Schutzstatus bestätigen: Berechtigungen kontrollieren, Ergebnis festhalten und Fehlermeldungen überwachen.

Für aktiv ausgenutzte Schwachstellen braucht es einen beschleunigten Ablauf außerhalb regulärer Wartungstermine. Je nach Lage kann auch eine vorübergehende Einschränkung einer betroffenen Funktion nötig sein. Ein Wartungsfenster darf kein Grund werden, dringende Sicherheitskorrekturen aufzuschieben.

Außerdem sollten nicht sämtliche Hintergrundaufgaben zusammen mit den Updates deaktiviert werden. WordPress verwendet seinen Aufgabenplaner beispielsweise für zeitgesteuerte Beiträge und Update-Prüfungen; Erweiterungen können weitere Aufgaben ergänzen. [6] Bestellverarbeitung, Synchronisationen und andere benötigte Abläufe müssen weiterhin zuverlässig ausgelöst werden.

5. Ein anderer Login-Pfad kann Bots ausbremsen – mit Grenzen

Der bekannte WordPress-Login wird von automatisierten Anfragen angesteuert. Ein abweichender Anmeldeweg kann einfache Skripte ausfiltern, die ausschließlich die Standardadresse verwenden. Er ist eine ergänzende Maßnahme zur Reduzierung unerwünschter Anfragen, keine neue Authentifizierung.

Wichtig ist, den Standardweg tatsächlich abzufangen, ohne die benötigten Anmeldefunktionen zu beschädigen. Dazu gehören Passwort-Zurücksetzen, Abmeldung, erneute Anmeldung nach Ablauf einer Sitzung und gegebenenfalls externe Anmeldedienste. WordPress-Kerndateien sollten dafür nicht bei jedem Update manuell umbenannt werden müssen.

Warum ein Redirect nicht automatisch Serverlast spart

Eine Weiterleitung zur Startseite kann den Aufruf des Login-Formulars unterbinden. Ob sie den Server entlastet, hängt jedoch davon ab, wo sie erfolgt. Lädt dafür zunächst WordPress vollständig, wurde PHP bereits beschäftigt. Folgt der Bot anschließend der Weiterleitung, kommt eine weitere Anfrage hinzu.

Wenn Lastreduzierung das Ziel ist, sollte geprüft werden, ob unerwünschte Anfragen bereits vor dem Start von WordPress begrenzt oder abgewiesen werden können. Ein anderer Login-Pfad bleibt zudem auffindbar; Angriffe auf andere erreichbare Funktionen verhindert er nicht.

Zur eigentlichen Absicherung der Anmeldung gehören starke individuelle Zugangsdaten, Mehrfaktor-Authentifizierung und eine Begrenzung wiederholter Anmeldeversuche. OWASP behandelt diese Maßnahmen ausdrücklich als Schutz gegen automatisierte Angriffe. [7]

Eine Wirkung würde ich anhand vergleichbarer Vorher-nachher-Zeiträume beurteilen: Wie viele Anfragen erreichen noch PHP? Wie verändern sich fehlgeschlagene Anmeldungen, Prozessauslastung und Antwortzeiten? Ohne solche Messungen lässt sich keine seriöse Prozentzahl nennen. Weniger Einträge in einem WordPress-Protokoll bedeuten allein noch nicht, dass die Bots ihre Anfragen eingestellt haben.

6. Für welche Websites lohnt sich dieses Betriebskonzept?

Besonders sinnvoll ist die Trennung, wenn eine Website laufend redaktionell genutzt wird, Änderungen an Plugins und Themes aber ohnehin durch eine technische Betreuung erfolgen. Das passt beispielsweise zu Unternehmenswebsites, Portalen oder Shops mit abgestimmten Veröffentlichungs- und Wartungsprozessen.

Voraussetzung ist eine Hosting-Umgebung, in der sich die benötigten Rechte und Webserver-Regeln umsetzen lassen. Ein eigener Server bietet Gestaltungsmöglichkeiten, bringt aber auch Verantwortung mit. Ein entsprechend betreutes Hosting kann denselben organisatorischen Zweck erfüllen. Entscheidend ist, wer die Schutzmaßnahmen pflegt und bei Störungen oder Sicherheitsmeldungen handelt.

Vor einer Einführung würde ich klären: Welche Dateien muss die Anwendung schreiben? Wer darf neue Software bereitstellen? Welche Funktionen werden nach Änderungen geprüft? Wie schnell werden Sicherheitsupdates eingespielt? Und lässt sich die Website aus einer Sicherung tatsächlich wiederherstellen?

Die Umstellung sollte zunächst in einer Testumgebung erfolgen. Bei einer bereits infizierten Website steht vorher die Bereinigung an. Ein reibungsloser Übergang ist das Ziel; eine Garantie auf keinerlei Unterbrechung lässt sich ohne Prüfung der Installation nicht geben.