Die Konfigurationsdatei wp-config.php ist das technische Herz jeder WordPress Installation. Diese unscheinbare PHP-Datei enthält alle wesentlichen Informationen, die für den Betrieb einer WordPress-Webseite nötig und von Relevanz sind. Genau dieser Fakt macht sie aber auch zum absoluten Sicherheitsrisiko, wenn die Datei nicht ausreichend gegen Hackerangriffe geschützt ist. Deshalb zeigt dieser Beitrag, wie man durch eine modifizierte .htaccess und weitere Maßnahmen die wp-config absichern und vor Angriffen und Exploits schützen kann.
Inhalt und Funktion der wp-config.php
Die Konfigurationsdatei wird vom WordPress Core für eine Vielzahl an Funktionsaufrufen, Authentifizierungsmaßnahmen und Verbindungen zur Datenbank benötigt. Es sollte einleuchten, dass der Inhalt dieser Datei ziemlich brisant ist und in jedem Fall vor der NSA oder kriminellen, computer-affinen Jugendlichen aus Osteuropa geschützt werden sollte. Um zu verstehen, warum der Inhalt dieser Datei so schützenswert ist, schauen wir uns in den folgenden Zeilen einfach mal an, was genau in diesem Stück PHP Code eigentlich so drin steht.
Dabei beziehen wir uns erst einmal auf eine cleane wp-config.php auf Basis der Sample-Datei, die WordPress beim Download eines frischen WordPress-ZIPS mitliefert. Der nachfolgende Screenshot zeigt, worüber ich hier rede. Diese Datei wird später mit den eigenen (hochbrisanten!) Informationen angepasst, umbenannt und zurück in den Webspace geladen, bevor die WordPress Installation starten kann.
Wird die WordPress Installation über ein Werkzeug erledigt, das durch den Hoster zur Verfügung gestellt wird ( beispielsweise ein „one click setup“ etc.), sollte man diese Schritte einmal manuell durchspielen. Ein Grundverständnis über die elementaren Funktionen von WordPress ist die wichtigste Voraussetzung für einen sicheren Betrieb der Webseite. Beim Betrieb einer WordPress-Multisite nimmt die wp-config noch einige zusätzliche Einträge auf, die hier an dieser Stelle nicht weiter berücksichtigt werden.
Datenbankeinträge der wp-config absichern
Die Datenbankeinträge kommen unmittelbar am Anfang der wp-config.php und sind zusammen mit den Login-Informationen eines Admins die empfindlichsten Informationen, die deine WordPress-Webseite zu bieten hat. Aus diesem Grund ist es besonders wichtig, dass wir diese hochsensiblen Informationen der wp-config absichern und vor unbefugtem Zugriff schützen!
Die Datenbankinformationen benötigt WordPress für jeden schreibenden und lesenden Zugriff aller Softwarekomponenten (auch der Plugins) auf die zugehörige MySQL Datenbank.
Werden diese Informationen durch einen gewerblichen Hacker oder kleinkriminellen Jugendlichen abgefangen, ist definitiv Schicht im WordPress-Schacht. Gerade die Datenbank kann sensible personenbezogene Informationen enthalten, die im Kontext der aktuellen DSGVO nicht unbedingt in die falschen Hände gelangen sollten.
Die Einträge erklären sich für jeden IT-Einsteiger aber wohl fast von selbst.
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');
/** MySQL database username */
define('DB_USER', 'username_here');
/** MySQL database password */
define('DB_PASSWORD', 'password_here');
/** MySQL hostname */
define('DB_HOST', 'localhost');
Der MySQL Hostname sollte im Zweifelsfall direkt beim Hoster angefragt werden, falls beim default-Wert „localhost“ Probleme auftreten. Nur ein paar Zeilen weiter treffen wir auf den Eintrag „Charset“ und „Database Collate type„:
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');
Unicode UTF-8 ist der quasi Standard für die Darstellung von Zeichen aller Sprachen und muss in der Regel nicht angepasst werden. Sonderfälle mit unterschiedlichen Sprachen können mit DB_COLLATE angepasst werden. Wird hier kein Sonderfall angegeben, wird der default-Wert aus dem Charset herangezogen. Also keine Sorge, wenn dich die beiden Einträge ratlos zurücklassen. Hier musst du i.d.R. keine Hand anlegen, wenn du nicht gerade an der Sortiergenauigkeit und Sortierperformance in der Datenbank Änderungen vornehmen möchtest.
WordPress Keys and Salts
Nur wenige Zeilen weiter wird es nicht minder spannend. Auch wenn diese spätestens beim Besuch des hinterlegten Links unter https://api.wordpress.org/secret-key/1.1/salt/ sehr kryptisch wirkenden Informationen das rot blinkende Fragezeichen im Unterbewusstsein anspringen lassen, hat dieser Eintrag elementare Bedeutung für die Sicherheit von WordPress.
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
define('AUTH_SALT', 'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT', 'put your unique phrase here');
define('NONCE_SALT', 'put your unique phrase here');
Welche Aufgabe haben diese Keys und Salts?
WordPress nutzt für die Verifizierung und Speicherung von temporären Login-Informationen wie Passwörtern, Nutzernamen oder Session-Timestamps keine PHP-Sessions, sondern einfache krümelige Cookies. Diese Informationen werden aber nicht als Klartext gespeichert, sondern mit Hilfe kryptographischer Funktionen gehasht.
Das Hashing ist dabei eine nicht injektive mathematische Abbildung der Informationen auf eine „verschlüsselte“ Zeichenfolge, aus der die Ursprungsinformationen ohne Wissen über den verwendeten Hash-Algorithmus und seiner Teilinformationen nicht wiederhergestellt werden kann.
Die Keys und Salts sind Bestandteil genau dieser Hashfunktionen und verschlüsseln die in den Cookies gespeicherten Informationen auf eine nicht reproduzierbare Weise. Das setzt allerdings voraus, dass die Keys & Salts auch sicher vor dem Zugriff Unbefugter sind – die wp-config muss also adäquat abgesichert sein. Diese 8 Schlüssel müssen bei jedem WordPress Setup in der wp-config.php konfiguriert und gespeichert werden, damit das Hashing von sensiblen Informationen einwandfrei funktioniert. Die von WordPress zur Verfügung gestellte API haben wir weiter oben bereits einmal verlinkt.
Schlüsselpaare sollten nur ein einziges mal verwendet (also keinesfalls für mehrere WordPress-Installationen!) und von Zeit zu Zeit erneuert werden. Ein Renew der Schlüsselpaare führt zur Ungültigkeit der Login-Sessions angemeldeter Nutzer (auch Admins) und kann somit als akute Maßnahme gegen ungebetene Hacker-Eindringlinge in das WordPress Backend eingesetzt werden.
WordPress Datenbank-Tabellenpräfix
Der Tabellenpräfix gilt für alle Tabellen in der Datenbank, die WordPress mit der Installation anlegt und ist auch für die Installation mehrerer WordPress Installationen in einer Datenbank wichtig. Wer diesen Eintrag vor der Installation von WordPress anpasst, sorgt dafür, dass etwaige Exploit-Skripte von Hackern ins Leere laufen. Derartige Standard-Skripte zielen auf den default-Präfix von WordPress ab, der normalerweise mit „wp_“ beginnt.
/** * WordPress Database Table prefix. * * You can have multiple installations in one database if you give each * a unique prefix. Only numbers, letters, and underscores please! */ $table_prefix = 'wp_';
Dieses Präfix kann in eine beliebige Zeichenfolge geändert werden. Der Übersicht halber sollte 2-5 alphanumerische Zeichen reichen, wie z.B: „wepe_“ oder „ab12-„. Die nachträgliche Änderung der Tabellenpräfixe bei bereits aktiver WordPress-Seite erfordert eine vollständige Anpassung der Datenbankinhalte via Search & Replace.
Ein längeres Tabellenpräfix sollte vermieden werden, weil einige Tabellennamen 64 Zeichen nicht überschreiten können. Ansonsten kann es bei der Installation zusätzlicher Tabellen, wie z.B. durch das Shop-Plugin WooCommerce, zu Fehlern im Programmverhalten kommen.
WordPress Debugging
Die letzte WP_DEBUG Zeile entscheidet darüber, ob WordPress Debugging-Informationen produziert oder nicht. Debugging wird eingesetzt, um potentielle Fehler, die durch den Quellcode produziert werden, aufzudecken. Das können falsche oder ungültige Methodenaufrufe, fehlerhafte Dateiverweise oder auch Syntax-Fehler im Quellcode sein, die dann entsprechend eine Fehlermeldung produzieren, die aber auch im Browser ausgegeben wird.
Doch genau diese Ausgabe der Fehlermeldung stellt ein entscheidendes Sicherheitsrisiko dar. Denn die zum Teil umfangreichen Debug-Infos geben hin und wieder Informationen preis, die von Hackern und Angreifern sonst nur in feuchten Träumen so mühelos erbeutet werden können.
Ein Beispiel sind Pfade zu Dateien, verwendete Plugins, veralteten PHP-Versionen, Sicherheitslücken oder ungültige und veraltete Methoden, die direkt im Browser ausgegeben werden. Deshalb gilt es es die Debugging-Informationen um jeden Preis zu schützen. Wir müssen unbefugten Zugriff in der wp-config absichern und die Ausgabe der Debugging-Informationen also einfach deaktivieren.
Standardmäßig ist das Debugging deaktiviert. Das hat seinen guten Grund.
define('WP_DEBUG', false);
Eine mögliche Adaption dieser Einstellung wäre die folgende Variante:
- Aktivierung des Debuggings
- Sperre für die Ausgabe von Fehlermeldungen im Browser
- stattdessen das Logging in einem separaten File unter /wp-content/debug.log
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_DISPLAY', false ); define( 'WP_DEBUG_LOG', true );
Aufpassen angesagt! Die in der debug.log enthaltenen Informationen sind nicht minder sensibel. Für die sichere Speicherung sollten man die Dateirechte und Verzeichnisrechte dringend überprüfen und das Verzeichnis wp-content umbenennen.
Absoluter Pfad von WordPress
Das Ende der default-Konfigurationsdatei bildet der absolute Pfad zum WordPress Verzeichnis. Das Ändern des Wertes von ABSPATH ist allerdings nicht nötig. Außerdem wird noch die Datei wp-settings.php eingebunden, die weitere Dateien lädt und die Funktionen des WordPress-Cores, Plugins und Themes initialisiert. Hier muss ebenfalls keine Änderung stattfinden.
/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');
Durch .htaccess wp-config absichern
Hört sich unnötig kompliziert an, ist aber verdammt einfach und effektiv. Denn mit einem kleinen Eintrag in der Server-Konfigurationsdatei .htaccess können Verzeichnisse mit diversen Maßnahmen und Berechtigungen besonders geschützt und abgesichert werden. Auf diesem Wege lässt sich also auch die wp-config absichern.
Bei einer aktiven WordPress Installation liegt bereits eine .htaccess-Datei im Hauptverzeichnis. Dort sind seitens WordPress schon einige Angaben vorhanden, die bei einer neuen Installation etwa so aussehen:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Um den Zugang zur Datei aktiv zu unterbinden, erweitert man die .htaccess um folgenden Inhalt unterhalb von # END WordPress:
<Files wp-config.php> order allow,deny deny from all </Files>
Weitere Sicherheitsmaßnahmen für WordPress und wp-config.php
Die hier aufgezeigten Schritte bilden nur eine Grundabsicherung der wp-config.php. Die Datei lässt sich zusammen mit weiteren Maßnahmen umfangreich erweitern, um die WordPress Sicherheit massiv anzuheben. Kontaktieren Sie uns, um weitere Schritte für die erhöhte Sicherheit Ihrer WordPress Website zu erfahren.
