WordPress absichern: klare Checkliste

WordPress sichern Sie wirksam ab, indem Sie zuerst veralteten Code entfernen, administrative Zugänge begrenzen und eine getestete Wiederherstellung einrichten. Danach folgen sichere Dateirechte, verschlüsselte Verbindungen, Protokollierung und ein Notfallplan. Ein Sicherheits-Plugin oder das Verbergen der Versionsnummer ersetzt keine dieser Grundlagen und schafft allein keine belastbare Schutzwirkung.

Beginnen Sie mit dem aktualisierbaren System

Die wichtigste Schutzmaßnahme ist unspektakulär: WordPress-Core, PHP, Plugins und Themes müssen unterstützt und aktuell sein. Eine bekannte Lücke bleibt durch eine hübsche Login-Seite nicht weniger bekannt. Entfernen Sie Erweiterungen und Themes, die nicht gebraucht werden; Deaktivieren allein lässt ihren Code auf dem Server liegen.

Prüfen Sie vor einem Update, ob eine verwertbare Sicherung vorhanden ist. Aktualisieren Sie anschließend in einer Testumgebung oder in einem Wartungsfenster, kontrollieren Sie Anmeldung, Formulare, Zahlungen und geplante Aufgaben. Erst wenn diese Kernwege funktionieren, ist das Update betrieblich abgeschlossen.

Zuständigkeit gehört zum Leistungsumfang. Bei Managed Hosting muss klar sein, wer Core, PHP, Erweiterungen, Webserver und Datenbank aktualisiert. Ein Anbieter kann die Plattform pflegen, ohne Ihre Plugins zu betreuen. Lassen Sie sich die Grenze schriftlich erklären und legen Sie intern fest, wer Warnungen bewertet.

Halten Sie für jede Installation ein kurzes Betriebsblatt aktuell:

• verantwortliche Person für Updates und Sicherheitsmeldungen,
• eingesetzte Erweiterungen mit ihrem geschäftlichen Zweck,
• Ort und Aufbewahrung der Sicherungen,
• Alarmweg sowie Kontakt zum Hosting-Anbieter.

Begrenzen Sie Konten statt nur Passwörter zu verlängern

Jede Person erhält ein eigenes Konto. Sammelkonten wie Redaktion oder Agentur verhindern eine saubere Zuordnung und machen den Entzug einzelner Zugänge unnötig schwer. Vergeben Sie die kleinste passende Rolle: Wer Beiträge schreibt, braucht gewöhnlich keine Rechte zum Installieren von Plugins oder zum Ändern von Benutzern.

Administratorrechte sind Arbeitsmittel, kein Status. Halten Sie die Zahl privilegierter Konten klein, sperren Sie ausgeschiedene Personen sofort und prüfen Sie regelmäßig, ob Agenturen oder Dienstleister noch Zugriff benötigen. Dasselbe gilt für Hosting-Konto, Domainverwaltung, DNS, Datenbank und Serverzugang.

Mehrfaktor-Authentisierung gehört mindestens vor privilegierte Zugänge. Bevorzugen Sie ein Verfahren, das Phishing erschwert, und testen Sie die Wiederherstellung ohne das übliche Mobilgerät. Ein zweiter Faktor ohne dokumentierten Ersatzweg kann im Störfall zur selbst gebauten Aussperrung werden.

Anwendungspasswörter sind für API-Zugriffe gedacht, nicht für die Anmeldung im Browser. Geben Sie jeder Integration ein eigenes, widerrufbares Zugangsmittel und benennen Sie dessen Zweck. Wird ein Dienst beendet, widerrufen Sie genau dieses Passwort, statt das Hauptpasswort einer Person an mehrere Werkzeuge weiterzugeben.

Verschlüsseln Sie Übertragung und schützen Sie Geheimnisse

TLS muss die öffentliche Website und den Administrationsbereich vollständig abdecken. Prüfen Sie nicht nur die Startseite, sondern auch Anmeldung, Medienabrufe, Weiterleitungen und externe Endpunkte. Zugangsdaten gehören weder in unverschlüsselte FTP-Verbindungen noch in E-Mails oder gemeinsam genutzte Notizen.

Die Konfigurationsdatei enthält Datenbankzugang und Sicherheitsschlüssel. Sie darf nicht öffentlich abrufbar sein und sollte nur für die Konten lesbar sein, die sie tatsächlich benötigen. Zugangsdaten für Datenbank, Hosting, DNS und Integrationen werden getrennt verwaltet; ein kompromittiertes WordPress-Konto soll nicht automatisch den gesamten Betrieb öffnen.

Schlüsselrotation ist ein Eingriff mit Folgen. Nach einem bestätigten Vorfall ist das Erneuern der WordPress-Sicherheitsschlüssel sinnvoll, weil bestehende Sitzungen dadurch ungültig werden. Im Normalbetrieb ersetzt häufiges Drehen ohne Anlass weder sichere Konten noch ein gepflegtes System.

Setzen Sie Dateirechte nach Eigentümermodell, nicht nach Rezept

Pauschale rekursive chmod-Befehle sind riskant, weil Shared Hosting, PHP-FPM, Container und verwaltete Plattformen unterschiedliche Eigentümermodelle verwenden. Entscheidend ist die Grenze: Der Webprozess soll Anwendungscode nicht allgemein überschreiben können. Schreibrechte bekommt er nur dort, wo Uploads, Cache oder ein ausdrücklich betreuter Aktualisierungsweg sie benötigen.

Prüfen Sie besonders Plugin- und Theme-Verzeichnisse, die Konfigurationsdatei sowie temporäre Upload-Pfade. Wenn WordPress für Updates volle Schreibrechte auf den gesamten Webroot verlangt, klären Sie zuerst Eigentümer und Prozessbenutzer mit dem Hoster. Bequeme Schreibbarkeit vergrößert den Schaden, falls ein Angreifer Code ausführen kann.

Der integrierte Datei-Editor kann abgeschaltet werden. Das nimmt einem übernommenen Administratorkonto einen naheliegenden Weg zur Codeänderung, verhindert aber keine schädlichen Uploads und keine bereits vorhandene Lücke. Behandeln Sie diese Einstellung als Begrenzung des Schadens, nicht als primären Schutz.

Ordnen Sie XML-RPC und API-Zugänge nach tatsächlicher Nutzung

XML-RPC ist nicht automatisch unnötig. Mobile Anwendungen, externe Veröffentlichungswerkzeuge oder bestimmte Dienste können davon abhängen. Prüfen Sie zuerst Zugriffsprotokolle und Integrationen. Wenn kein legitimer Bedarf besteht, kann der Endpunkt am Server oder vorgeschalteten Dienst begrenzt werden; bei Nutzung braucht er dieselben Kontrollen gegen automatisierte Anmeldeversuche wie andere Zugänge.

Anwendungspasswörter sind die sauberere Wahl für unterstützte API-Integrationen, weil sie einzeln benannt und widerrufen werden können. Verwenden Sie sie nur über TLS und mit einem Benutzer, dessen Rolle zum Auftrag passt. Ein Veröffentlichungswerkzeug benötigt keine Rechte zur Installation von Erweiterungen.

Das Verbergen der WordPress-Version ist höchstens eine kleine Hürde für oberflächliche Scanner. Versionshinweise lassen sich oft an mehreren Stellen ableiten. Primäre Kontrolle bleibt das zeitnahe Schließen der Lücke; kosmetische Verschleierung darf ein überfälliges Update nie rechtfertigen.

Bauen Sie Schutzschichten mit klarer Verantwortung

Die Reihenfolge ist bewusst: Erst Angriffsfläche reduzieren, dann Zugriffe und Schreibrechte begrenzen, anschließend Wiederherstellung und Reaktion absichern. Die Grafik verdichtet diese Aufgaben, ersetzt aber nicht die Zuordnung zu einer verantwortlichen Person.

Sichern Sie so, dass eine Rückkehr möglich ist

Eine Sicherung ist erst belastbar, wenn sie Datenbank und Dateien umfasst, außerhalb des betroffenen Hosting-Kontos liegt und tatsächlich zurückgespielt wurde. Eine Momentaufnahme auf demselben Konto kann bei Kontosperre, Fehlkonfiguration oder umfassender Kompromittierung gleichzeitig mit der Website ausfallen.

Legen Sie Aufbewahrung und Häufigkeit nach dem Verlustfenster fest: Wie viele Bestellungen, Anfragen oder redaktionelle Änderungen dürfen fehlen? Halten Sie mehrere zeitlich getrennte Stände vor. Sonst kann die einzige verbleibende Kopie bereits denselben schädlichen Code enthalten wie das laufende System.

Ein Rücksicherungstest braucht einen Zielort, eine verantwortliche Person und eine Erfolgskontrolle. Prüfen Sie nach dem Restore nicht nur die Startseite, sondern Anmeldung, Medien, Formulare, E-Mail-Versand und zeitgesteuerte Aufgaben. Ein grüner Sicherungsbericht ist kein Restore-Test.

Überwachen Sie Änderungen, nicht nur Erreichbarkeit

Ein Uptime-Signal erkennt einen Totalausfall, aber keine neue Administratorrolle oder manipulierte Datei. Erfassen Sie mindestens Anmeldungen, fehlgeschlagene Zugriffe, Änderungen an Benutzern und Erweiterungen sowie unerwartete Dateiveränderungen. Leiten Sie Warnungen an einen Kanal, der auch außerhalb von WordPress erreichbar ist.

Produktive Seiten dürfen technische Fehler nicht für Besucher ausgeben. Diagnoseprotokolle gehören an einen nicht öffentlich erreichbaren Ort, mit begrenzter Aufbewahrung und geregeltem Zugriff. Prüfen Sie außerdem, ob Protokolle personenbezogene Daten oder Zugangsinformationen enthalten, bevor Sie sie dauerhaft speichern oder an Dienstleister senden.

Ein WAF kann bekannte schädliche Anfragen und massenhafte Anmeldeversuche vor WordPress filtern. Er repariert jedoch kein verwundbares Plugin, korrigiert keine zu breite Rolle und stellt keine Daten wieder her. Dasselbe gilt für Sicherheits-Plugins: Sie können Signale und Kontrollen liefern, übernehmen aber nicht die Betriebsverantwortung.

Legen Sie den Ablauf für einen Vorfall vorher fest

Wenn Sie unberechtigte Benutzer, Weiterleitungen, Malware-Warnungen oder veränderte Dateien entdecken, dokumentieren Sie Symptome und Zeitpunkte. Bewahren Sie Protokolle und eine Kopie des betroffenen Zustands auf, bevor Sie alles überschreiben. Klären Sie mit dem Hoster, ob weitere Websites oder Konten betroffen sind.

Begrenzen Sie danach den Zugriff: sperren Sie verdächtige Konten, widerrufen Sie Anwendungspasswörter, ändern Sie Zugangsdaten über ein sauberes Gerät und beenden Sie aktive Sitzungen. Stellen Sie Code und Daten aus einer vertrauenswürdigen Quelle wieder her, aktualisieren Sie alle Komponenten und prüfen Sie, über welchen Weg der Angriff gelang.

Wieder online ist nicht gleich bereinigt. Kontrollieren Sie Benutzer, geplante Aufgaben, Weiterleitungen, DNS, ausgehende E-Mails und Suchmaschinenwarnungen. Bei personenbezogenen Daten oder geschäftskritischen Systemen gehören Datenschutz, Kundenkommunikation und gegebenenfalls externe Forensik in die Eskalation.

Welche Maßnahmen passen zu Ihrem Betrieb?

Für eine kleine betreute Website ist Managed Hosting sinnvoll, wenn Updates, Sicherungen, Überwachung und Wiederherstellung eindeutig im Leistungsumfang stehen. Komfort braucht eine Ausstiegstür: Sie benötigen exportierbare Daten, eigene Domainkontrolle und einen dokumentierten Übergabeweg.

Für eine Agentur mit mehreren Installationen zählen ein einheitliches Inventar, getrennte Kundenkonten, zentrale Warnungen und wiederholbare Restore-Tests. Vermeiden Sie ein gemeinsames Administratorpasswort und unklare Übergaben zwischen Agentur, Kunde und Hoster.

Für einen selbst betriebenen Server brauchen Sie zusätzlich Betriebssystem-Patches, Webserver- und Datenbankhärtung, Protokollschutz und eine Vertretung für den Notfall. Wenn dafür keine verlässliche Zuständigkeit existiert, ist die zusätzliche Kontrolle meist nur zusätzliche, unbemerkte Arbeit.