So sichern Sie eine WordPress-Datenbank: Härtung, Verschlüsselung und laufender Schutz

Jede WordPress-Website läuft auf einer Datenbank. Sie speichert Ihre Beiträge, Ihre Benutzer, deren Passwörter, Ihre Plugin-Einstellungen und Ihre Kundenbestellungen.

Dateien auf dem Server speichern Ihr Theme und Ihre Bilder. Die Datenbank speichert alles andere.

Deshalb ist sie das Erste, was ein ernsthafter Angreifer ins Visier nimmt.

SQL-Injection ist immer noch ein gängiger Angriffsvektor für WordPress. Angreifer senden manipulierte Eingaben über Anmeldeformulare, Suchfelder oder anfällige Plugin-Felder, die die Datenbank dazu verleiten, Befehle auszuführen, die sie nicht ausführen sollte.

Eine erfolgreiche Injection kann neue Admin-Konten erstellen, Ihre Besucher auf Spam-Seiten umleiten, bösartigen Code in Ihre Inhalte einschleusen oder die Datenbank komplett löschen.

Die meisten dieser Angriffe machen keine Geräusche. Eingeschleuster Code und fehlerhafte Admin-Konten können wochenlang unbemerkt in einer Datenbank verweilen, bevor etwas Sichtbares schiefgeht.

Ich habe mit Websites gearbeitet, bei denen jedes Plugin aktualisiert war, die Zwei-Faktor-Authentifizierung aktiviert war und durchweg starke Passwörter verwendet wurden. Sie wurden trotzdem über eine Datenbankverbindung getroffen, die niemand gesichert hatte.

Darum geht es in diesem Tutorial.

Sie werden 13 Schritte zur Sicherung Ihrer Datenbank durchlaufen: Die ersten acht härten die Datenbank selbst und schließen die gängigsten Angriffswege, und die letzten fünf richten die Sicherungs-, Überwachungs- und Wiederherstellungsschicht ein, die Sie schützt, wenn die Härtung allein nicht ausreicht.

Am Ende werden Sie einen laufenden, proaktiven Schutz für Ihre Datenbank haben.

Hier sind die wichtigsten Erkenntnisse:

• Die 13 Schritte decken zwei Ebenen ab: Datenbankhärtung (Schritte 1–8) und Einrichtung von Sicherung, Überwachung und Wiederherstellung (Schritte 9–13). Sie benötigen beides, da die Härtung allein Sie nach einem Einbruch nicht schützt, wenn dieser durchkommt.
• Einige Datenbankeinbrüche zeigen tagelang oder wochenlang keine sichtbaren Symptome, daher ist die Überwachung über das Activity Log Plugin genauso wichtig wie die Sicherheits-Härtung.
• Eine unverschlüsselte Sicherungsdatei im Cloud-Speicher ist eine zweite Kopie Ihrer gesamten Datenbank. Jeder, der Zugriff auf dieses Speicherkonto erhält, kann sie lesen, ohne jemals Ihre Live-Website zu berühren – die Verschlüsselung in Schritt 9 schließt diese Lücke.
• Erstellen Sie ein vollständiges Website-Backup, bevor Sie mit Schritt 1 beginnen. Mehrere Schritte nehmen direkte Datenbankänderungen vor, die ohne ein solches Backup schwer rückgängig zu machen sind.
• Speichern Sie Ihre Duplicator-Notfallwiederherstellungs-URL außerhalb von WordPress während Schritt 11. Es ist das einzige Werkzeug, das Sie wieder hineinbringt, wenn Ihr Dashboard vollständig gesperrt ist, aber nur, wenn Sie es gespeichert haben, bevor die Dinge schiefgingen.
• Der Fehlerbehebungsbereich behandelt sechs Fehlerszenarien, einschließlich eines vollständigen Wiederherstellungspfads für den Fall, dass Ihre Website nicht reagiert und Ihr WordPress-Dashboard nicht geladen wird.

Inhaltsverzeichnis

Was ist eine WordPress-Datenbank?

WordPress speichert alle dynamischen Inhalte Ihrer Website in einer Datenbank. Wenn jemand Ihre Website besucht, fragt WordPress die Datenbank ab, ruft die relevanten Inhalte ab und setzt die Seite im Handumdrehen zusammen. Wenn Sie eine Einstellung ändern, einen Beitrag veröffentlichen oder einen Benutzer hinzufügen, wird dies in der Datenbank gespeichert.

Eine frische WordPress-Installation erstellt 12 Kern-Tabellen. Hier ist, was die wichtigsten enthalten:

• wp_posts: jeder Beitrag, jede Seite, jede Revision und jeder benutzerdefinierte Beitragstyp auf Ihrer Website
• wp_users: alle Benutzerkonten, Benutzernamen und gehashten Passwörter
• wp_usermeta: Benutzerrollen, Berechtigungen und Kontoeinstellungen
• wp_options: Website-weite Einstellungen, Plugin-Konfigurationen und Daten des aktiven Themes
• wp_comments: alle Kommentare von Besuchern und deren Metadaten

Plugins und Themes fügen ihre eigenen Tabellen zusätzlich zu den WordPress-Standardtabellen hinzu. Ein WooCommerce-Shop fügt Tabellen für Bestellungen, Produkte und Kundendaten hinzu. Ein Formular-Plugin fügt Tabellen für jede Einreichung hinzu.

Je mehr Sie auf WordPress aufbauen, desto mehr wächst Ihre Datenbank.

Warum Sie Ihre WordPress-Datenbank sichern müssen

Die Datenbank ist ein Ausfallpunkt, den jeder ernsthafte Angreifer anstrebt. Alles, was es wert ist, gestohlen oder zerstört zu werden, lebt dort.

SQL-Injection ist immer noch eine gängige Angriffsmethode. Ein Hacker sendet sorgfältig gestaltete Eingaben über ein Anmeldeformular, eine Suchleiste oder ein anfälliges Plugin-Feld. Wenn die Eingabe nicht ordnungsgemäß bereinigt wird, behandelt die Datenbank sie als Befehl und führt ihn aus.

Von dort aus kann der Angreifer Ihre gesamte Datenbank lesen und exportieren, neue Admin-Konten erstellen, bösartige Inhalte in Ihre Beiträge einschleusen oder alles auf einmal löschen.

Ihre wp-config.php-Datei ist das andere Hauptziel. Sie enthält Ihren Datenbanknamen, Benutzernamen und Ihr Passwort im Klartext. Ein Angreifer, der diese Datei erhält, benötigt nicht Ihre WordPress-Anmeldung. Er verbindet sich direkt mit der Datenbank und umgeht WordPress vollständig.

Was die meisten Website-Besitzer überrascht, ist, wie unauffällig diese Sicherheitsverletzungen sind. Illegale Admin-Konten und eingeschleuster Code brechen normalerweise nicht sofort etwas Sichtbares. Bis Sie die Spam-Weiterleitungen oder die manipulierten Inhalte bemerken, hatte der Angreifer oft wochenlang Zugriff.

Deshalb reicht eine reine Sicherheits-Härtung allein nicht aus. Sie benötigen auch eine Möglichkeit, Änderungen zu erkennen und aus einem sauberen Backup wiederherzustellen, wenn doch etwas durchkommt.

Was Sie vor dem Start benötigen

Bevor Sie Änderungen vornehmen, stellen Sie sicher, dass Sie alles unten Genannte vorhanden haben. Insbesondere das Überspringen des Backup-Schritts hat viele Leute bei Schritten wie der Änderung des Tabellenpräfixes verbrannt. Es ist das Risiko nicht wert.

• Zugriff auf das Hosting-Control-Panel. Sie müssen sich bei cPanel, MyKinsta, dem WP Engine Dashboard oder einem anderen Panel anmelden, das Ihr Hoster bereitstellt. Mehrere Schritte beinhalten phpMyAdmin, das sich normalerweise im Abschnitt Datenbanken Ihres Control Panels befindet.
• FTP-Zugriff oder Dateimanager. Sie benötigen eine Möglichkeit, Dateien auf Ihrem Server anzuzeigen und zu bearbeiten, insbesondere wp-config.php. Die meisten Hoster stellen einen Dateimanager direkt im Control Panel zur Verfügung.
• Ihre aktuellen Datenbankanmeldeinformationen. Öffnen Sie wp-config.php und suchen Sie die Werte DB_NAME, DB_USER, DB_PASSWORD und DB_HOST. Sie werden diese in den Schritten 3 bis 5 verwenden.
• Ein vollständiges Website-Backup, das vor Beginn erstellt wurde. Verwenden Sie ein Backup-Plugin wie Duplicator oder erstellen Sie ein manuelles Backup. Stellen Sie sicher, dass Sie Kopien Ihrer Website-Dateien und Ihrer Datenbank haben. Einige dieser Schritte nehmen direkte Änderungen an Ihrer Datenbank vor, und Sie benötigen einen sauberen Wiederherstellungspunkt, falls etwas schief geht.
• WordPress-Adminzugriff. Sie müssen für mehrere Schritte in diesem Tutorial als Administrator angemeldet sein.

So sichern Sie Ihre WordPress-Datenbank

Ich gebe Ihnen 13 einfache Schritte, um Ihre WordPress-Datenbank vor einem Angriff zu sichern.

Die ersten acht härten die Datenbank selbst und schließen die häufigsten Angriffspfade. Die Schritte 9 bis 13 richten die Backup-, Überwachungs- und Wiederherstellungsschicht ein, die Sie schützt, wenn Härtung allein nicht ausreicht.

Hier ist eine Übersicht darüber, was Sie tun werden:

• Schritt 1: Ändern Sie den Standard-Admin-Benutzernamen und die Benutzer-ID. Entfernen Sie die beiden am häufigsten angegriffenen Anmeldeinformationen bei automatisierten WordPress-Angriffen.
• Schritt 2: Ändern Sie das Standard-Datenbanktabellenpräfix. Ersetzen Sie das vorhersagbare wp_-Präfix, das SQL-Injection-Skripte anvisieren.
• Schritt 3: Erstellen Sie einen dedizierten Datenbankbenutzer mit eingeschränkten Berechtigungen. Beschränken Sie Ihren Datenbankbenutzer auf die vier Berechtigungen, die WordPress tatsächlich benötigt.
• Schritt 4: Deaktivieren Sie Remote-Datenbankverbindungen. Schließen Sie den externen Zugriff auf Ihre Datenbank auf MySQL-Konfigurationsebene.
• Schritt 5: Schützen Sie Ihre wp-config.php-Datei. Sichern Sie die Datei, die Ihre Datenbankanmeldeinformationen im Klartext speichert.
• Schritt 6: Aktivieren Sie SSL für Datenbankverbindungen. Verschlüsseln Sie Daten während der Übertragung zwischen WordPress und MySQL, wenn diese auf separaten Servern laufen.
• Schritt 7: Fügen Sie eine Web Application Firewall hinzu. Filtern Sie SQL-Injection-Versuche heraus, bevor sie Ihre Datenbank erreichen.
• Schritt 8: Bereinigen Sie verwaiste Plugin-Tabellen. Entfernen Sie verwaiste Tabellen, die von deinstallierten Plugins hinterlassen wurden und Ihre Datenbank aufblähen und ungepatchte Schwachstellen aufweisen.
• Schritt 9: Richten Sie verschlüsselte Backups ein. Aktivieren Sie die AES-256-Verschlüsselung, damit Ihre Backup-Dateien nicht ohne Ihren Schlüssel gelesen werden können, selbst wenn jemand sie direkt herunterlädt.
• Schritt 10: Planen Sie automatische Datenbank-Backups. Entfernen Sie menschliches Versagen aus Ihrer Backup-Routine, damit Sie immer einen aktuellen Wiederherstellungspunkt haben, egal wie beschäftigt es wird.
• Schritt 11: Speichern Sie Backups extern. Holen Sie Kopien von Ihrem Server, damit ein Breach auf Host-Ebene Ihre Wiederherstellungsoptionen nicht auslöschen kann.
• Schritt 12: Überwachen Sie Datenbankänderungen. Erfassen Sie die Erstellung von bösartigen Admin-Konten und unbefugte Änderungen in Echtzeit.
• Schritt 13: Testen Sie eine Datenbankwiederherstellung. Bestätigen Sie, dass Ihr Wiederherstellungsplan funktioniert, bevor Sie ihn benötigen.

Schritt 1: Ändern Sie den Standard-Admin-Benutzernamen und die Benutzer-ID

WordPress erstellt während der Installation einen Benutzer mit dem Benutzernamen „admin“ und der ID 1. Diese beiden Werte sind in fast jedem automatisierten Brute-Force- und SQL-Injection-Skript, das auf WordPress abzielt, fest einprogrammiert. Das Ändern dieser Werte entfernt zwei der am leichtesten vorhersagbaren Ziele in Ihrer Datenbank.

Hier ist eine einfache Methode, um Ihren Admin-Benutzernamen zu ändern, ohne die Datenbank anzufassen:

1. Erstellen Sie direkt in WordPress ein neues Administratorkonto
2. Melden Sie sich als dieser neue Benutzer an
3. Löschen Sie das ursprüngliche Admin-Konto
4. Weisen Sie dessen Inhalte dem neuen Konto zu

Wenn Sie die Änderung direkt in der Datenbank vornehmen müssen, erfahren Sie hier, wie Sie dies über phpMyAdmin tun können.

Melden Sie sich über Ihr Hosting-Control-Panel bei phpMyAdmin an, wählen Sie Ihre WordPress-Datenbank aus der linken Seitenleiste aus und klicken Sie auf die Registerkarte SQL. Führen Sie die folgenden Abfragen nacheinander aus:

UPDATE wp_users SET user_login = 'yournewname' WHERE user_login = 'admin';

UPDATE wp_users SET ID = 101 WHERE ID = 1;

UPDATE wp_posts SET post_author = 101 WHERE post_author = 1;

UPDATE wp_usermeta SET user_id = 101 WHERE user_id = 1;

Alle vier Abfragen sind notwendig. Ihre Benutzer-ID erscheint in wp_users, wp_posts und wp_usermeta. Wenn Sie also nur die erste Tabelle aktualisieren, bleiben in den anderen beiden fehlerhafte Verweise bestehen.

Eine Warnung, bevor Sie etwas ausführen: Erstellen Sie zuerst ein vollständiges Backup. Ein Tippfehler in einer direkten SQL-Abfrage kann Ihre Website auf eine Weise beschädigen, die ohne ein solches Backup schwer rückgängig zu machen ist.

Ich verwende dafür gerne Duplicator. Es verfügt über anfängerfreundliche Backup-Voreinstellungen, die Ihnen schnelle Kopien Ihrer Datenbank oder Ihrer gesamten Website ermöglichen.

Duplicator verfügt über die besten Wiederherstellungswerkzeuge aller Backup-Plugins, die ich ausprobiert habe. Sie werden später in diesem Tutorial sehen, wie sie funktionieren!

Um zu bestätigen, dass die Änderung funktioniert hat, melden Sie sich von WordPress ab und mit Ihrem neuen Benutzernamen wieder an. Ihr Dashboard sollte genau wie zuvor geladen werden.

Schritt 2: Ändern Sie das Standard-Datenbanktabellenpräfix

WordPress benennt standardmäßig jede Datenbanktabelle mit dem Präfix wp_. SQL-Injection-Skripte, die auf WordPress abzielen, sind darauf aufgebaut.

Das Ändern des Präfixes in etwas Unvorhersehbares wird einen ausgeklügelten Angreifer allein nicht aufhalten, aber es entfernt Ihre Website aus dem Pool der Ziele, die automatisierte Tools im ersten Durchgang treffen.

Es gibt zwei Möglichkeiten, dies zu tun: Verwenden Sie ein Sicherheits-Plugin (für die meisten Benutzer empfohlen) oder nehmen Sie die Änderungen manuell über phpMyAdmin vor.

Plugin-Methode (empfohlen)

Die Plugin-Methode ist die sicherere Wahl für Anfänger, da sie serialisierte Daten automatisch verarbeitet. Einige Plugin-Optionstabellen speichern das Präfix in serialisierten PHP-Daten, und eine einfache SQL-Suche und -Ersetzung kann diese Daten beschädigen, wenn sie nicht sorgfältig behandelt werden.

All-In-One Security enthält ein Datenbankpräfix-Tool mit integrierten Schutzmaßnahmen.

Installieren Sie Ihr gewähltes Plugin, navigieren Sie zu dessen Datenbank-Tools-Bereich und führen Sie die Präfixänderung von dort aus. Das Plugin aktualisiert wp-config.php, benennt alle Tabellen um und verarbeitet Referenzen auf serialisierte Daten in einem Durchgang.

Manuelle Methode

Wenn Sie Ihr Datenbanktabellenpräfix lieber manuell ändern möchten, gehen Sie wie folgt vor.

Öffnen Sie zuerst wp-config.php über FTP oder den Dateimanager und aktualisieren Sie die Zeile $table_prefix mit Ihrem neuen Präfix. Verwenden Sie nur Buchstaben, Zahlen und Unterstriche:

$table_prefix = 'site82_';

Zweitens, melden Sie sich bei phpMyAdmin an, wählen Sie Ihre WordPress-Datenbank aus und öffnen Sie die Registerkarte SQL. Führen Sie eine RENAME TABLE-Abfrage für jede Tabelle in Ihrer Datenbank aus:

RENAME TABLE wp_posts TO site82_posts;

RENAME TABLE wp_users TO site82_users;

Repeat this for all 12 core tables and any tables added by plugins.

Aktualisieren Sie als Nächstes die Tabelle wp_options, die Zeilen enthält, die in der Spalte option_name immer noch auf das alte Präfix verweisen:

UPDATE site82_options SET option_name = REPLACE(option_name, 'wp_', 'site82_') WHERE option_name LIKE 'wp_%';

Aktualisieren Sie abschließend die Tabelle wp_usermeta aus demselben Grund:

UPDATE site82_usermeta SET meta_key = REPLACE(meta_key, 'wp_', 'site82_') WHERE meta_key LIKE 'wp_%';

Überprüfen Sie Ihre aktiven Plugins, nachdem Sie diese Abfragen ausgeführt haben. Einige Plugins speichern das Präfix in ihren eigenen Datenzeilen und müssen diese ebenfalls aktualisiert werden. Wenn etwas nicht funktioniert, ist Ihr Backup vor der Änderung der schnellste Weg zurück zu einem funktionierenden Zustand.

Um zu bestätigen, dass alles funktioniert hat, besuchen Sie die Homepage Ihrer Website und melden Sie sich dann ab und wieder in Ihrem WordPress-Dashboard an. Beides sollte genau wie zuvor funktionieren.

Schritt 3: Erstellen Sie einen dedizierten Datenbankbenutzer mit eingeschränkten Rechten

Wenn WordPress installiert ist, erstellen die meisten Hosting-Setups einen Datenbankbenutzer mit vollen administrativen Rechten für die gesamte Datenbank. WordPress benötigt normalerweise nur vier grundlegende Berechtigungen zum Ausführen: SELECT, INSERT, UPDATE und DELETE. Jede darüber hinausgehende Berechtigung könnte ein zusätzliches Risiko darstellen.

Wenn ein Angreifer eine Plugin-Schwachstelle ausnutzt und Zugriff auf Ihre Datenbankanmeldeinformationen erhält, sind eingeschränkte Rechte der Unterschied zwischen dem Lesen Ihrer Daten und dem Löschen Ihrer gesamten Datenbank.

Es gibt zwei Möglichkeiten, dies anzugehen: Beschränken Sie die Rechte des vorhandenen Datenbankbenutzers oder erstellen Sie einen neuen dedizierten Benutzer mit nur den Berechtigungen, die WordPress benötigt.

Beschränken von Rechten über phpMyAdmin

Melden Sie sich bei phpMyAdmin an, klicken Sie oben auf Benutzerkonten, suchen Sie Ihren WordPress-Datenbankbenutzer in der Liste und klicken Sie auf Rechte bearbeiten. Deaktivieren Sie alles außer SELECT, INSERT, UPDATE und DELETE. Scrollen Sie nach unten und klicken Sie auf OK, um zu speichern.

Erstellen eines neuen dedizierten Benutzers über SQL

Wenn Sie eine saubere Einrichtung bevorzugen, führen Sie diese Abfragen im SQL-Tab von phpMyAdmin aus:

CREATE USER 'wpuser_secure'@'localhost' IDENTIFIED BY 'StrongPasswordHere';

GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser_secure'@'localhost';

FLUSH PRIVILEGES;

If you create a new user, update your wp-config.php file with the new credentials:

define('DB_USER', 'wpuser_secure');

define('DB_PASSWORD', 'StrongPasswordHere');

Ein wichtiger Hinweis: Einige Plugins und wichtige WordPress-Core-Updates benötigen CREATE- oder ALTER-Berechtigungen, um Datenbanktabellen während der Installation hinzuzufügen oder zu ändern. Wenn eine Plugin-Installation nach diesem Schritt fehlschlägt, gewähren Sie diese Berechtigungen vorübergehend erneut, schließen Sie die Installation ab und widerrufen Sie sie dann wieder.

Wenn Sie mehrere WordPress-Websites auf demselben Server betreiben, verwenden Sie für jede eine völlig separate Datenbank und einen separaten Datenbankbenutzer. Wenn eine Website kompromittiert wird, verhindert diese Eindämmung, dass der Angreifer die anderen erreicht.

Um zu bestätigen, dass die Berechtigungen korrekt festgelegt sind, erstellen Sie einen Entwurfbeitrag in WordPress, speichern Sie ihn und löschen Sie ihn. Wenn alle drei Aktionen erfolgreich sind, hat Ihr Datenbankbenutzer die benötigten Rechte und nichts mehr.

Schritt 4: Deaktivieren Sie Remote-Datenbankverbindungen

Bei den meisten WordPress-Setups laufen WordPress und MySQL auf demselben Server. Es gibt keinen Grund, externen IPs den direkten Zugriff auf Ihre Datenbank zu erlauben. Wenn der Fernzugriff geöffnet bleibt, kann ein Angreifer versuchen, sich von überall im Internet bei MySQL zu authentifizieren und WordPress vollständig zu umgehen.

Es gibt zwei Stellen, an denen Sie dies absperren können, und Sie sollten beide überprüfen.

MySQL-Konfiguration

Wenn Sie Ihren eigenen Server verwalten (VPS oder Cloud-Hosting), suchen Sie Ihre MySQL-Konfigurationsdatei. Sie befindet sich normalerweise unter /etc/mysql/mysql.conf.d/mysqld.cnf. Suchen Sie die Zeile bind-address und stellen Sie sicher, dass sie auf 127.0.0.1 gesetzt ist:

bind-address = 127.0.0.1

Wenn sie auf 0.0.0.0 gesetzt ist, ändern Sie sie in 127.0.0.1 und starten Sie MySQL neu, um die Änderung zu übernehmen:

sudo systemctl restart mysql

Hostname des Datenbankbenutzers

Selbst wenn MySQL an den Localhost gebunden ist, lohnt es sich zu überprüfen, ob Ihr WordPress-Datenbankbenutzer auch auf Benutzerebene auf lokale Verbindungen beschränkt ist.

Klicken Sie in phpMyAdmin auf Benutzerkonten und suchen Sie Ihren WordPress-Datenbankbenutzer. Die Spalte Host sollte localhost oder 127.0.0.1 anzeigen. Wenn Sie ein %-Wildcard sehen, kann dieser Benutzer von jeder IP-Adresse aus eine Verbindung herstellen.

Löschen Sie alle Benutzer, die auf % gesetzt sind, und erstellen Sie sie mit localhost als Host neu:

DROP USER 'wpuser'@'%';

CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'YourPassword';

GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser'@'localhost';

FLUSH PRIVILEGES;

Shared-Hosting-Benutzer

Wenn Sie sich im Shared Hosting befinden und keinen Zugriff auf die MySQL-Konfigurationsdatei haben, überprüfen Sie stattdessen Ihr Control Panel. Suchen Sie in cPanel nach Remote MySQL im Abschnitt Datenbanken.

Entfernen Sie alle dort aufgeführten IP-Adressen. Das ist das Äquivalent zum Schließen des Remote-Zugriffs auf Hosting-Ebene.

Um zu bestätigen, dass der Remote-Zugriff deaktiviert ist, sollte Ihr WordPress-Datenbankbenutzer in der Benutzerkonten-Ansicht von phpMyAdmin localhost als einziger erlaubter Host anzeigen.

Schritt 5: Schützen Sie Ihre wp-config.php-Datei

Ihre wp-config.php-Datei enthält Ihren Datenbanknamen, Benutzernamen, Ihr Passwort und Ihre Authentifizierungsschlüssel im Klartext. Wenn ein Angreifer diese Datei lesen kann, hat er alles, was er braucht, um sich direkt mit Ihrer Datenbank zu verbinden. Sie ist eine der ersten Dateien, die bei jedem WordPress-Angriff ins Visier genommen werden.

Wenden Sie alle drei der folgenden Schutzmaßnahmen gemeinsam an. Jede schließt eine andere Schwachstelle.

1. Verschieben Sie die Datei über das Web-Root-Verzeichnis

WordPress sucht automatisch ein Verzeichnis über dem Root, wenn es wp-config.php nicht an Ort und Stelle finden kann. Sie können die Datei also verschieben, ohne Einstellungen zu ändern. Wenn Ihr Website-Root /public_html ist, verschieben Sie wp-config.php nach /home/username/. Verwenden Sie FTP oder den Dateimanager Ihres Hosters, um dies zu tun.

Dies funktioniert bei den meisten Standard-Hosting-Setups, aber einige Managed-Hosting-Anbieter erlauben es nicht. Wenn Ihr Hoster den Zugriff über das Web-Root-Verzeichnis einschränkt, fahren Sie mit den nächsten beiden Schutzmaßnahmen fort.

2. Blockieren Sie den Webzugriff über .htaccess

Fügen Sie die folgende Regel zu Ihrer .htaccess-Datei hinzu, die sich in Ihrem WordPress-Root-Verzeichnis befindet. Dies weist Apache an, alle Browseranfragen für die Datei direkt abzulehnen, auch wenn jemand den Pfad kennt:

<Files wp-config.php>

order allow,deny

deny from all

</Files>

Wenn Ihr Hoster eine neuere Apache-Konfiguration verwendet, verwenden Sie stattdessen diese Version:

<Files "wp-config.php">

Require all denied

</Files>

3. Setzen Sie die Dateiberechtigungen auf 400 oder 440

Dateiberechtigungen steuern, welche Benutzer auf dem Server eine Datei lesen, schreiben oder ausführen können. Wenn Sie wp-config.php auf 400 setzen, kann nur der Dateibesitzer sie lesen. Wenn Sie sie auf 440 setzen, wird der Lesezugriff auch auf die Servergruppe erweitert, was einige Hosting-Konfigurationen erfordern.

Klicken Sie im Dateimanager Ihres Hosters mit der rechten Maustaste auf wp-config.php, wählen Sie Berechtigungen ändern und geben Sie 400 ein. Über FTP können Sie die meisten Clients die Datei mit der rechten Maustaste anklicken und die Berechtigungen direkt festlegen.

Um zu bestätigen, dass alle drei Schutzmaßnahmen vorhanden sind, versuchen Sie, im Browser auf yourdomain.com/wp-config.php zuzugreifen. Sie sollten eine 403 Forbidden-Fehlermeldung erhalten.

Schritt 6: SSL für Datenbankverbindungen aktivieren

Wenn WordPress und MySQL auf demselben Server laufen, bleiben die Daten lokal und durchqueren niemals ein Netzwerk. Wenn Ihre Datenbank jedoch auf einem separaten Server läuft (häufig bei VPS-Setups, Cloud-Hosting oder verwalteten Umgebungen), reisen diese Daten über eine Netzwerkverbindung. Ohne SSL reisen sie im Klartext, einschließlich Anmeldeinformationen und Sitzungs-Tokens.

Wenn Sie Standard-Shared-Hosting mit WordPress und MySQL auf demselben Server verwenden, können Sie diesen Schritt überspringen. Wenn Sie eine Multi-Server-Architektur oder ein Cloud-Setup verwenden, bei dem Ihre Datenbank separat läuft, tun Sie dies nicht.

Prüfen Sie zuerst bei Ihrem Hoster

Viele Managed-Hosting-Anbieter kümmern sich automatisch um SSL für Datenbankverbindungen. Kinsta, WP Engine und Cloudways erzwingen verschlüsselte Datenbankverbindungen auf Infrastrukturebene. Überprüfen Sie die Dokumentation Ihres Hosters, bevor Sie manuelle Änderungen vornehmen – Sie sind möglicherweise bereits abgedeckt.

SSL auf dem MySQL-Server aktivieren

Wenn Sie Ihren eigenen Server verwalten, fügen Sie Ihrer mysqld.cnf-Datei Folgendes hinzu, um SSL-Zertifikate zu konfigurieren und verschlüsselte Verbindungen zu erzwingen:

[mysqld]

ssl-ca = /path/to/ca.pem

ssl-cert = /path/to/server-cert.pem

ssl-key = /path/to/server-key.pem

require_secure_transport = ON

Starten Sie MySQL nach dem Speichern der Datei neu.

WordPress anweisen, SSL zu verwenden

Fügen Sie die folgende Zeile zu Ihrer wp-config.php-Datei hinzu, oberhalb der Zeile, die lautet /* Das ist alles, bearbeiten Sie nicht weiter! */:

define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);

Dies weist die Datenbankverbindung von WordPress an, SSL bei der Verbindung zu MySQL zu erzwingen.

Um zu bestätigen, dass SSL aktiv ist, überprüfen Sie das Fehlerprotokoll Ihres MySQL-Servers, nachdem WordPress seine nächste Datenbankverbindung hergestellt hat. Sie sollten SSL als aktiv für den Anwendungsbenutzer aufgeführt sehen.

Schritt 7: Fügen Sie eine Web Application Firewall hinzu

Die Datenbankhärtung in den vorherigen Schritten reduziert Ihre Angriffsfläche erheblich. Aber sie eliminiert nicht das Risiko, dass ein anfälliges Plugin zu einem Einfallstor für SQL-Injection wird.

Eine Web Application Firewall (WAF) sitzt vor Ihrer Website und filtert bösartige Anfragen heraus, bevor sie WordPress oder Ihre Datenbank erreichen.

Für die Datensicherheit ist die wichtigste Aufgabe einer WAF das Erkennen von SQL-Injection-Mustern in Formulareingaben, URL-Parametern und Anforderungsheadern und deren Blockierung, bevor sie ausgeführt werden. Sie blockiert auch bösartige IPs und Bots, reduziert Brute-Force-Anmeldeversuche und führt ein Protokoll der blockierten Anfragen, das Sie überprüfen können, wenn etwas verdächtig erscheint.

Drei WAF-Optionen eignen sich gut für die meisten WordPress-Websites:

• Wordfence: Wird direkt als WordPress-Plugin installiert. Die kostenlose Stufe enthält eine WAF mit grundlegendem SQL-Injection-Schutz. Die Premium-Stufe fügt Echtzeit-Bedrohungsdaten und schnellere Regelaktualisierungen hinzu.
• Sucuri: Bietet einen Plugin-basierten Scanner und eine WAF auf DNS-Ebene. Die Option auf DNS-Ebene leitet den gesamten Datenverkehr über das Netzwerk von Sucuri, bevor er Ihren Server erreicht, was einen stärkeren Schutz bietet, aber einen kostenpflichtigen Plan erfordert.
• Cloudflare: Eine WAF auf DNS-Ebene mit einer kostenlosen Stufe, die grundlegende Angriffsfilterung abdeckt. Die kostenpflichtigen Pläne fügen granularere Regeln und eine bessere Abdeckung für Angriffe auf Anwendungsebene hinzu.

Wenn Sie nach der Einrichtung Firewall-Regeln anpassen müssen, testen Sie alle Änderungen auf einer Staging-Kopie Ihrer Website, bevor Sie sie in der Produktion anwenden. Eine falsch konfigurierte Regel kann legitimen Datenverkehr blockieren – Kontaktformulare, Checkout-Prozesse und Admin-Aktionen sind häufige Opfer.

Eine WAF ist eine ergänzende Schicht, kein Ersatz für die Härtungsschritte, die Sie bereits abgeschlossen haben. Betrachten Sie sie als den Filter, der alles auffängt, was an allem anderen vorbeigleitet.

Schritt 8: Bereinigen Sie verwaiste Plugin-Tabellen

Wenn Sie ein Plugin in WordPress deinstallieren, bleiben dessen Datenbanktabellen normalerweise zurück. WordPress löscht sie nicht automatisch, und die meisten Plugins bereinigen sich bei der Deinstallation nicht selbst.

Im Laufe der Zeit blähen diese verwaisten Tabellen Ihre Datenbank auf und schaffen ein verstecktes Sicherheitsrisiko: Eine Tabelle eines Plugins mit einer bekannten SQL-Injection-Schwachstelle ist immer noch ausnutzbar, auch nachdem das Plugin selbst verschwunden ist.

Um verwaiste Tabellen zu identifizieren, verwenden Sie ein Plugin wie WP-Optimize oder Advanced Database Cleaner. Beide scannen Ihre Datenbank und kennzeichnen Tabellen, die keinem aktuell aktiven Plugin entsprechen.

Installieren Sie eines, führen Sie einen Datenbankoptimierungs-Scan durch und überprüfen Sie die Ergebnisse, bevor Sie etwas löschen.

Sie können die Tabellenliste auch manuell in phpMyAdmin überprüfen. Wählen Sie Ihre WordPress-Datenbank aus der linken Seitenleiste aus und durchsuchen Sie die Tabellenliste. Tabellen, die nicht mit Ihrem aktuellen $table_prefix übereinstimmen oder den Namen eines Plugins tragen, das Sie nicht mehr verwenden, sind Kandidaten für die Entfernung.

Erstellen Sie jedoch zuerst ein frisches Datenbank-Backup. Das Löschen einer Tabelle ist permanent, und einige Tabellen, die verlassen erscheinen, werden noch aktiv genutzt.

Seien Sie besonders vorsichtig bei Tabellen, die mit WooCommerce, Formular-Plugins wie Gravity Forms oder WPForms und Mitgliedschafts- oder LMS-Plugins verbunden sind. Diese speichern oft Transaktionsdatensätze, Formularübermittlungen und Benutzerdaten, die Sie möglicherweise benötigen, auch wenn das Plugin nicht mehr aktiv ist.

Gleichen Sie jede Kandidaten-Tabelle mit Ihrer Liste der aktiven Plugins ab, bevor Sie sie entfernen. Wenn Sie nicht sicher sind, zu welchem ​​Plugin eine Tabelle gehört, suchen Sie nach dem Tabellennamen zusammen mit dem Wort „WordPress“, um das Plugin zu identifizieren, das sie erstellt hat.

Um eine bestätigte verwaiste Tabelle in phpMyAdmin zu löschen, wählen Sie die Tabelle aus, klicken Sie auf Operations und scrollen Sie nach unten, um auf Drop Table zu klicken. Alternativ können Sie sie über den SQL-Tab ausführen:

DROP TABLE old_plugin_table_name;

Um zu bestätigen, dass die Bereinigung reibungslos verlief, führen Sie nach dem Entfernen von Tabellen einen schnellen Funktionstest auf Ihrer Website durch. Überprüfen Sie Ihre Homepage, senden Sie ein Testformular, falls vorhanden, und melden Sie sich ab und wieder an.

Schritt 9: Richten Sie verschlüsselte Backups ein

Die obigen Schritte verringern die Wahrscheinlichkeit eines erfolgreichen Angriffs auf Ihre Datenbank. Dieser Schritt ist das, was Sie aus einem herausbringt.

Die meisten Leute denken bei Backups an ein Werkzeug zur Notfallwiederherstellung. Je nachdem, wie Sie sie erstellen, können sie auch ein Sicherheitsrisiko darstellen.

Eine unverschlüsselte Backup-Datei in einem Google Drive-Ordner ist eine zweite Kopie Ihrer gesamten Datenbank. Jeder, der Zugriff auf dieses Speicherkonto erhält, kann sie herunterladen, öffnen und jeden Benutzerdatensatz, jedes Passwort-Hash und jede Kundenbestellung lesen, ohne jemals Ihre Live-Site zu berühren. Verschlüsselung macht diese Datei ohne Ihren Schlüssel nutzlos.

Deshalb verschlüssele ich Backups immer mit Duplicator. Dieses Plugin ermöglicht es Ihnen, AES-256-Verschlüsselung für jedes Backup zu aktivieren.

AES-256 ist der gleiche Verschlüsselungsstandard, der von Finanzinstituten und Regierungssystemen verwendet wird. Wenn er aktiviert ist, ist Ihr Backup-Archiv ohne Passwort vollständig unlesbar, selbst wenn jemand die Datei direkt von Ihrem Speicher-Account herunterlädt.

Zwei Dinge, die Sie tun sollten, bevor Sie speichern: Schreiben Sie dieses Passwort auf und speichern Sie es in einem Passwort-Manager. Wenn Sie es verlieren, werden Ihre verschlüsselten Backups dauerhaft unzugänglich. Bewahren Sie eine Kopie außerhalb von WordPress auf.

Schritt 10: Planen Sie automatische Datenbank-Backups

Ein verschlüsseltes Backup schützt Sie nur, wenn Sie tatsächlich eines haben, wenn etwas schiefgeht.

Manuelle Backups scheitern in der Praxis, weil das Leben dazwischenkommt. Sie erinnern sich vielleicht daran, eines vor einem großen Update auszuführen, vielleicht nach einer Migration, gelegentlich, wenn sich etwas komisch anfühlt. Was Sie nicht tun, ist, es jeden einzelnen Tag ohne Ausnahme auszuführen.

Diese Lücke ist der Unterschied zwischen einem sauberen Rollback und einem unordentlichen. Wenn ein Angreifer heute einen bösartigen Admin-Account erstellt oder bösartige Inhalte injiziert und Sie es erst zwei Wochen später bemerken, benötigen Sie ein Backup von davor.

Ein täglicher Zeitplan gibt Ihnen einen sauberen Wiederherstellungspunkt, der nie älter als 24 Stunden ist. Eine Gewohnheit manueller Backups gibt Ihnen, was auch immer Sie zuletzt ausgeführt haben.

Navigieren Sie in Ihrem WordPress-Dashboard zu Duplicator Pro » Schedule Backup und klicken Sie auf Add New. Benennen Sie den Backup-Zeitplan und wählen Sie eine Vorlage. Sie könnten zum Beispiel eine Vorlage für Datenbank-Backups erstellen.

Wählen Sie einen Speicherort. Duplicator unterstützt lokale Backups sowie beliebte Cloud-Speicher wie Duplicator Cloud, Google Drive, Amazon S3 und Google Cloud.

Legen Sie die Häufigkeit fest, basierend darauf, wie aktiv Ihre Website ist.

Tägliche Datenbank-Backups sind die richtige Wahl für jede Website, die regelmäßig Inhalte veröffentlicht, Bestellungen bearbeitet oder aktive Benutzerkonten hat. Wöchentlich eignet sich für statische oder wenig besuchte Websites, bei denen sich die Datenbank selten ändert.

Schritt 11: Speichern Sie Backups extern mit Duplicator Cloud

Ein Backup, das auf demselben Server wie Ihre Website gespeichert ist, ist kein echtes Backup. Wenn Ihr Server kompromittiert wird, Ransomware Ihre Dateien verschlüsselt oder Ihr Hoster einen katastrophalen Ausfall erleidet, verlieren Sie Ihr Backup im selben Moment, in dem Sie Ihre Website verlieren.

Off-Site-Speicherung ist das, was „Ich habe alles verloren“ von „Ich habe in 20 Minuten wiederhergestellt“ trennt.

Duplicator Cloud ist die einfachste Option für die Speicherung von WordPress-Backups. Sie wurde für WordPress-Backups entwickelt, lässt sich direkt in Duplicator Pro integrieren und erfordert keine API-Authentifizierung.

Wenn Sie eine Alternative bevorzugen, unterstützt Duplicator Pro auch Google Drive, Amazon S3, Dropbox, OneDrive und jeden S3-kompatiblen Speicheranbieter, einschließlich Cloudflare R2, Backblaze B2 und DigitalOcean Spaces.

Sobald Ihr Speicher verbunden ist, bearbeiten Sie Ihren Backup-Zeitplan und stellen Sie ihn so ein, dass Kopien nach jeder Ausführung automatisch an Ihren verbundenen Speicheranbieter gesendet werden.

Behalten Sie mindestens eine Kopie auf Ihrem Host und eine Kopie im Cloud-Speicher außerhalb des Standorts. Für kritische Websites oder solche, die Kundendaten verarbeiten, bietet eine dritte lokal heruntergeladene Kopie eine zusätzliche Schutzschicht.

Wenn Sie wiederherstellen müssen, kann Duplicator Pro direkt aus Ihrem verbundenen Cloud-Speicher ziehen, ohne das Archiv zuerst auf Ihren Server herunterladen zu müssen.

Navigieren Sie zu Duplicator Pro » Backups. Suchen Sie ein Cloud-Backup und klicken Sie auf Wiederherstellen. Dies ist schneller als ein manueller Download und funktioniert auch dann, wenn Ihre lokalen Backup-Kopien nicht mehr vorhanden sind.

Selbst wenn Sie keinen Zugriff auf Ihr wp-admin-Dashboard haben, können Sie ein Cloud-Backup wiederherstellen. Ihr Duplicator Cloud-Dashboard ermöglicht es Ihnen, jedes Backup sofort remote zurückzusetzen, sogar teilweise Datenbank-Backups!

Schritt 12: Überwachen Sie Datenbankänderungen mit Activity Log

Die häufigste Aktion, die ein Angreifer nach dem Erhalt von Datenbankzugriff durchführt, ist die Erstellung eines unrechtmäßigen Admin-Kontos. Dies gibt ihnen eine dauerhafte Möglichkeit, auf ihre Website zurückzukehren, selbst nachdem der ursprüngliche Einstiegspunkt geschlossen und bereinigt wurde.

Ohne Überwachung kann dieses Konto wochenlang unbemerkt bleiben. Mit einem Aktivitätsprotokoll-Plugin wird es in dem Moment angezeigt, in dem es erstellt wird.

Aktivitätsprotokoll zeichnet jede Aktion auf Ihrer WordPress-Website mit Zeitstempel und IP-Adresse auf. Sie behalten mühelos den Überblick über Benutzeranmeldungen, die Erstellung neuer Konten, Rollenänderungen und Einstellungsänderungen.

Für die Datensicherheit sind die wichtigsten Ereignisse neue Benutzer, die Sie nicht erstellt haben, Rollenerhöhungen, bei denen ein Konto niedrigerer Ebene plötzlich Administratorzugriff erhält, und Anmeldeversuche von unbekannten IP-Adressen.

Aktivitätsprotokoll ist kostenlos bei Duplicator Elite enthalten. Sobald Ihr Plan aktiv ist, laden Sie das Plugin herunter und installieren Sie es in WordPress. Es beginnt sofort mit der Nachverfolgung.

Überprüfen Sie das Protokoll regelmäßig auf drei Dinge.

1. Jedes neue Benutzerkonto, das Sie nicht kennen.
2. Jeder vorhandene Benutzer, dessen Rolle ohne Ihr Zutun geändert wurde.
3. Jede Anmeldung von einer IP-Adresse, die nicht mit den Standorten Ihres Teams übereinstimmt.

Jedes dieser Anzeichen kann auf einen aktiven Einbruch oder eine Kompromittierung hinweisen, die vor Tagen oder Wochen stattgefunden hat.

Aktivitätsprotokoll ermöglicht es Ihnen, das Protokoll nach Benutzer, Aktionstyp oder Datumsbereich zu filtern und die Ergebnisse zu exportieren. Dies ist sowohl für routinemäßige Audits als auch für die Reaktion auf Vorfälle nützlich, bei denen Sie genau feststellen müssen, wann eine unbefugte Änderung stattgefunden hat.

Schritt 13: Testen Sie Ihre Datenbankwiederherstellung

Die meisten Leute stellen fest, dass ihr Backup kaputt ist, genau dann, wenn sie den größten Druck haben, sich schnell zu erholen. Ein Test dauert nur wenige Minuten. Eine fehlgeschlagene Wiederherstellung während eines aktiven Vorfalls kostet Sie weitaus mehr.

Die Ein-Klick-Staging-Funktion von Duplicator Pro ermöglicht es Ihnen, ein Backup auf eine separate Staging-URL wiederherzustellen, ohne Ihre Live-Site zu berühren. Erstellen Sie unter Duplicator Pro » Staging eine neue Staging-Site.

Wählen Sie ein aktuelles Voll-Site-Backup als Vorlage. Wählen Sie ein eindeutiges Admin-Farbschema, um Ihre Staging- und Live-Sites zu unterscheiden.

Sobald Duplicator Ihre Staging-Site erstellt hat, haben Sie eine vollständige Replik Ihrer Live-Site. Dies ist ein effektives Testgelände für die Durchführung von Testwiederherstellungen.

Laden Sie ein Backup auf die Seite Backups importieren von Duplicator hoch. Gehen Sie die Staging-Site nach Abschluss der Wiederherstellung durch.

Überprüfen Sie Ihre Homepage, melden Sie sich im WordPress-Dashboard an, öffnen Sie einige Beiträge und stellen Sie sicher, dass Ihre Plugin-Einstellungen korrekt sind. Wenn etwas fehlt oder kaputt ist, haben Sie das Problem jetzt gefunden, anstatt während einer echten Wiederherstellung.

Um zu bestätigen, dass Ihr Wiederherstellungstest erfolgreich war, sollte Ihre Staging-Site sauber mit allen Inhalten, Benutzern und Einstellungen aus dem Sicherungsdatum geladen werden.

Fehlerbehebung bei Problemen mit der Datensicherheit

Selbst wenn Sie jeden Schritt sorgfältig befolgen, können Dinge schiefgehen. Hier sind die häufigsten Fehlerpunkte und wie Sie sie überwinden können.

Ihre Website wird nach der Änderung des Tabellenpräfixes leer

Was Sie sehen: Ein weißer Bildschirm oder eine generische PHP-Fehlermeldung unmittelbar nach der Änderung des Tabellenpräfixes.

Warum es passiert: Die häufigste Ursache ist eine übersehene Tabellenreferenz. Einige Plugins speichern das alte Präfix in serialisierten PHP-Daten in den Tabellen „options“ oder „usermeta“. Wenn eine rohe SQL-Abfrage die Tabellennamen aktualisiert hat, aber diese internen Referenzen übersehen hat, kann WordPress nicht finden, wonach es sucht.

So beheben Sie es: Stellen Sie sofort ein Backup wieder her. Genau deshalb ist dieses Backup unerlässlich, bevor Sie mit diesen Schritten zur Datensicherheit beginnen.

Sobald Sie wieder einen funktionierenden Zustand erreicht haben, verwenden Sie ein Plugin wie All-In-One Security, um die Präfixänderung stattdessen vorzunehmen. Deren Tools verarbeiten serialisierte Daten automatisch und hinterlassen mit weitaus geringerer Wahrscheinlichkeit fehlerhafte Referenzen.

WordPress kann keine Verbindung zur Datenbank herstellen, nachdem wp-config.php bearbeitet wurde

Was Sie sehen: Eine Meldung „Fehler beim Herstellen einer Datenbankverbindung“ im Frontend oder ein leerer weißer Bildschirm.

Warum es passiert: Ein Tippfehler in einem der Datenbank-Anmeldedaten ist die häufigste Ursache. Das Verschieben von wp-config.php an einen Ort, den Ihr Server nicht finden kann, ist die zweithäufigste. Zu restriktive Dateiberechtigungen (wie 000) können auch verhindern, dass WordPress die Datei liest.

So beheben Sie es: Stellen Sie eine Verbindung über FTP oder Dateimanager her und öffnen Sie wp-config.php direkt. Überprüfen Sie, ob DB_NAME, DB_USER, DB_PASSWORD und DB_HOST alle korrekt sind und genau mit denen in Ihrem Hosting-Control-Panel übereinstimmen. Wenn Sie die Datei verschoben haben, stellen Sie sicher, dass sie sich ein Verzeichnis über dem WordPress-Stammverzeichnis befindet, nicht tiefer. Setzen Sie die Berechtigungen auf 400 oder 440, wenn sie auf etwas anderes geändert wurden.

Ein Plugin funktioniert nach der Einschränkung der Datenbankberechtigungen nicht mehr

Was Sie sehen: Ein Plugin wirft einen Fehler, kann Einstellungen nicht speichern oder zeigt eine datenbankbezogene Benachrichtigung an, nachdem Sie Schritt 3 abgeschlossen haben.

Warum es passiert: Einige Plugins benötigen CREATE- oder ALTER-Berechtigungen, um ihre eigenen Datenbanktabellen zu installieren oder zu aktualisieren. Sobald diese Berechtigungen widerrufen sind, kann das Plugin die erforderlichen Strukturänderungen nicht vornehmen.

So beheben Sie es: Erteilen Sie Ihrem Datenbankbenutzer vorübergehend über phpMyAdmin CREATE- und ALTER-Berechtigungen erneut. Aktualisieren oder installieren Sie das Plugin neu, lassen Sie es seine Einrichtung abschließen und widerrufen Sie diese Berechtigungen dann erneut. Dies ist ein normaler Teil der Aufrechterhaltung einer Datenbankkonfiguration mit minimalen Rechten.

Nichts funktioniert mehr: Vollständiger Wiederherstellungspfad

Wenn Ihre Website nicht reagiert, Ihr WordPress-Dashboard gesperrt ist und Sie nicht auf normalem Wege darauf zugreifen können, nutzen Sie eine der Notfallwiederherstellungsoptionen von Duplicator.

Für Backups, die in Duplicator Cloud gespeichert sind, können Sie diese remote wiederherstellen. Ihre Website ist dann ohne zusätzliche Fehlerbehebung wieder online.

Bevor es zu Katastrophen kommt, können Sie ein Backup auch als Wiederherstellungspunkt in WordPress festlegen. Speichern Sie die URL zur Notfallwiederherstellung an einem sicheren Ort.

Wenn Ihre Website nicht funktioniert, fügen Sie diese URL in einen Webbrowser ein und folgen Sie den Anweisungen.

Wenn Sie keine Notfallwiederherstellung oder Cloud-Backups eingerichtet haben, wenden Sie sich an die Notfall-Support-Hotline Ihres Hosting-Anbieters. Die meisten Managed-Hosts führen eigene Snapshots auf Serverebene. Für Websites, die gerade angegriffen werden und bei denen Malware in Echtzeit verbreitet wird, bieten Wordfence und Sucuri kostenpflichtige Notfall-Reaktionsdienste an.

Häufig gestellte Fragen (FAQs)

Sie haben Ihre Datenbank gehärtet. So halten Sie sie auch gehärtet.

Wenn Sie alle diese Schritte durchgearbeitet haben, ist Ihre Datenbank in einem besseren Zustand als die Mehrheit der derzeit laufenden WordPress-Websites.

Die Arbeit ist jedoch noch nicht abgeschlossen. Die Sicherheit der Datenbank ist keine einmalige Einrichtung. Es ist eine Wartungspraxis.

Überprüfen Sie Ihr Aktivitätsprotokoll monatlich und suchen Sie nach allem, was nicht mit Ihrer eigenen Aktivität übereinstimmt. Testen Sie vierteljährlich eine Wiederherstellung – Speicherverbindungen laufen ab, Verschlüsselungspasswörter gehen verloren, und der einzige Weg, um zu wissen, ob Ihre Backups verwendbar sind, ist, eines zu verwenden.

Überprüfen Sie Ihre Datenbank-Benutzerberechtigungen nach jeder neuen Plugin-Installation erneut, da einige Plugins bei Updates Berechtigungen wieder eskalieren, ohne dies offensichtlich zu machen. Und wenn Sie jemals zu einem neuen Host migrieren, führen Sie die Schritte 4 und 5 erneut von Grund auf neu durch. Remote-Zugriffseinstellungen und Dateiberechtigungen werden nicht immer so übertragen, wie Sie es erwarten würden.

Nachdem Sie diese Einrichtung abgeschlossen haben, erstellen Sie ein reines Datenbank-Backup und kennzeichnen Sie es deutlich als Ihre Baseline nach der Härtung. Wenn Sie in einigen Monaten einen Einbruch untersuchen müssen, gibt Ihnen diese Baseline einen sauberen Referenzpunkt zum Vergleichen.

Über 1,5 Millionen WordPress-Profis verwenden Duplicator Pro für Backups, Migrationen, Staging und Notfallwiederherstellung. Es ist das Werkzeug hinter AES-256-verschlüsselten Archiven, Duplicator Cloud Off-Site-Speicher, Ein-Klick-Wiederherstellungen, reinen Datenbank-Wiederherstellungen und Notfallwiederherstellungs-URLs, die Sie wieder online bringen, selbst wenn WordPress selbst nicht mehr lädt.

Wenn dieses Tutorial hilfreich war, sind diese Anleitungen auch lesenswert.

• So optimieren Sie Ihre WordPress-Datenbank
• Hier sind die Schritte zur Reparatur der WordPress-Datenbank, die ich selbst durchgeführt habe (kein Entwickler erforderlich)
• WordPress-Datenbankwartung: Was Sie wöchentlich, monatlich und vierteljährlich tun sollten
• Ist WordPress sicher? Die Wahrheit enthüllt
• So schützen Sie Ihre Website vor Hackern (Umfassender Sicherheitsleitfaden)
• So stellen Sie eine gehackte WordPress-Website wieder her (9 Expertentipps)