Priorität 1: vertrauenswürdige Basis
- WordPress, Plugins, Designvorlagen, PHP und Serverkomponenten aktualisieren
- ungenutzte Plugins, Designvorlagen und Konten vollständig entfernen
- WordPress-Kerndateien und verfügbare Erweiterungen gegen bekannte Quellen prüfen
- Administratorrechte auf notwendige Personen und Dienste begrenzen
- Passwörter, Sitzungen, Salts, API-Schlüssel und Anwendungspasswörter erneuern
Priorität 2: Ausführung und Zugänge begrenzen
PHP-Ausführung gehört in Upload-, Cache- und anderen Datenverzeichnissen grundsätzlich gesperrt, sofern die konkrete Anwendung dort keinen ausführbaren Code benötigt. Dateirechte folgen Least Privilege. Dashboard-Dateieditoren werden deaktiviert, administrative Zugriffe erfolgen verschlüsselt und besonders privilegierte Konten erhalten Mehrfaktor-Authentifizierung.
Hostingabhängig
Apache-, Nginx-, CDN- und Managed-Hosting-Konfigurationen unterscheiden sich. Regeln müssen zur tatsächlichen Plattform passen und anschließend funktional getestet werden.
Priorität 3: Wiederherstellung und Erkennung
- automatisierte, getrennt gespeicherte Datensicherungen mit Wiederherstellungstest
- geprüfter Integritätsstand für kontrollierte Dateien
- zentrale Protokolle mit passender Aufbewahrung und Zugriffsschutz
- Alarmierung bei neuen Administratoren, Dateiänderungen und WAF-Ereignissen
- dokumentierter Kontakt und Eskalationsweg für Sicherheitsvorfälle
Eine grüne Scanner-Anzeige ist keine dauerhafte Sicherheitsgarantie. Kontrollen müssen zur Umgebung passen und regelmäßig verifiziert werden.
Abnahme
Jede Maßnahme wird mit Verantwortlichem, Datum, Test und verbleibendem Risiko dokumentiert. So bleibt erkennbar, welche Schutzschicht tatsächlich aktiv ist und welche Empfehlung noch offen ist.
Was muss vor der Absicherung geklärt sein?
Eine Absicherung repariert keinen ungeklärten Sicherheitsvorfall. Wenn noch unbekannte Administratoren, veränderte Dateien oder aktive Weiterleitungen bestehen, braucht die Umgebung zuerst eine Bereinigung. Andernfalls können neue Regeln Symptome verdecken, während Wege für eine erneute Infektion bestehen bleiben.
Erfassen Sie vor Änderungen Hostingmodell, Webserver, PHP-Version, Deploymentweg, Caching, CDN/WAF, E-Mail-Versand, Cronjobs und externe Integrationen. Eine Regel, die auf einem einzelnen Apache-Setup funktioniert, kann bei Nginx oder Managed Hosting wirkungslos sein oder Funktionen blockieren.
Wie wird die Angriffsfläche verkleinert?
Jede installierte Komponente, Identität und Schnittstelle braucht einen geschäftlichen Zweck. Entfernen Sie deaktivierte Plugins und Themes vollständig statt sie nur auszuschalten. Löschen Sie ehemalige Administratoren nach dokumentierter Prüfung. Begrenzen Sie XML-RPC, REST-Endpunkte und Remote-Zugänge nur dort, wo der reale Nutzungskontext das erlaubt.
Updates sind notwendig, aber kein isolierter Kontrollpunkt. Prüfen Sie vorab Backups und Kompatibilität, aktualisieren Sie aus vertrauenswürdigen Quellen und testen Sie die wichtigsten Nutzerpfade. Für nicht mehr gepflegte Komponenten gibt es keinen dauerhaften sicheren Patchprozess; sie müssen ersetzt werden.
Welche Identitätskontrollen sind unverzichtbar?
Administrative Konten erhalten einzigartige Passwörter, Mehrfaktor-Authentifizierung und nur die tatsächlich benötigte Rolle. Gemeinsame Konten erschweren die Zuordnung von Änderungen. Dienstkonten und Anwendungspasswörter werden benannt, auf einen Zweck begrenzt und regelmäßig überprüft.
Trennen Sie WordPress-Administration von Hosting, DNS, CDN und E-Mail. Ein kompromittiertes Postfach kann Passwort-Resets ermöglichen; ein kompromittiertes DNS-Konto kann Besucher umleiten, obwohl WordPress selbst unverändert ist. Recovery-Codes gehören geschützt außerhalb der Website.
Wie sollten Dateien und Ausführung begrenzt werden?
Der Webserverprozess sollte nur dort schreiben können, wo die Anwendung es benötigt. Core-, Plugin- und Theme-Code wird idealerweise über einen kontrollierten Deploymentweg aktualisiert. In Upload- und Cacheverzeichnissen wird Skriptausführung gesperrt, sofern die Plattform dort keinen Code benötigt.
Vermeiden Sie pauschale Zahlenrezepte für Dateirechte. Eigentümer, Gruppen, PHP-Ausführungsmodell und Bereitstellung unterscheiden sich. Entscheidend ist, dass unprivilegierte Prozesse keine administrativen Dateien überschreiben können und Zugangsdaten nicht öffentlich lesbar sind.
Konfiguration testen
Eine Sicherheitsregel ist erst wirksam, wenn ihre Durchsetzung geprüft wurde. Testen Sie sowohl den blockierten Angriffspfad als auch Uploads, Formulare, Shop, Cron, REST-API und Deployment.
Welche Sicherheitsheader und Transportkontrollen helfen?
TLS schützt Daten auf dem Transportweg. HSTS kann Downgrades verhindern, darf aber erst nach vollständiger HTTPS-Abdeckung aktiviert werden. Content Security Policy reduziert bestimmte Browserangriffe, braucht jedoch eine auf die echte Website abgestimmte Direktivenliste. Weitere Header wie X-Content-Type-Options, Referrer Policy und Frame-Schutz ergänzen die Browsergrenzen.
Header ersetzen keine serverseitige Validierung und keine Bereinigung. Eine zu breite CSP mit zahlreichen Wildcards kann nur scheinbar streng wirken; eine überhastete Richtlinie kann Zahlungs-, Consent- oder Formularfunktionen unterbrechen.
Wie müssen Datensicherungen gestaltet sein?
Backups brauchen Trennung vom produktiven Account, verschlüsselte Übertragung, begrenzte Zugriffsrechte und eine Aufbewahrung, die mehrere Zeitpunkte abdeckt. Ein Backup im selben beschreibbaren Webverzeichnis kann zusammen mit der Website verändert oder gestohlen werden.
Mindestens ebenso wichtig ist der Wiederherstellungstest: Lässt sich eine definierte Version in einer isolierten Umgebung wiederherstellen? Sind Datenbank, Medien, Konfiguration und benötigte Zugangsdaten vollständig? Der Beitrag zu kompromittierten alten Datensicherungen erklärt, warum Alter allein keine Vertrauenswürdigkeit schafft.
Welche Erkennung ist realistisch?
Überwachen Sie neue privilegierte Benutzer, fehlgeschlagene Anmeldungen, Änderungen an kontrollierten Dateien, WAF-Ereignisse, unerwartete Cronjobs und starke Abweichungen im ausgehenden Traffic. Ein Alarm braucht Verantwortliche und einen Reaktionsweg; unbetreute Benachrichtigungen sind keine Kontrolle.
Speichern Sie Protokolle so, dass ein Angreifer im Hostingkonto sie nicht einfach mitlöschen kann. Legen Sie Aufbewahrungsfristen anhand Betriebs-, Sicherheits- und Datenschutzbedarf fest. Welche Quellen bei einem Sicherheitsvorfall zuerst gesichert werden sollten, beschreibt der Leitfaden zu Protokollen.
Wie sieht eine dokumentierte Abnahme aus?
Für jede Kontrolle werden Sollzustand, tatsächliche Konfiguration, Test, Ergebnis, Verantwortlicher und nächster Prüftermin festgehalten. Offene Punkte erhalten Priorität und eine begründete Frist. Diese Dokumentation erlaubt spätere Reviews und verhindert, dass „gehärtet“ nur eine einmalige Momentaufnahme bezeichnet.
Die Methodik verbindet diese Abnahme mit Befundklassen und Aussagegrenzen. Für Hosting- und Firewallkontrollen zeigt die Seite Server-Absicherung zusätzliche Ebenen außerhalb von WordPress.