WordPress absichern: Für jeden Webmaster sollte das Thema Sicherheit hohe Priorität besitzen, um sich und seine Besucher zu schützen. Doch nicht immer ist das der Fall. Oftmals fehlt das technische Verständnis für Hacking-Risiken und was mit kompromittieren Websites angestellt werden kann. In diesem Beitrag zeigen wir euch, wie ihr mithilfe der config-php WordPress absichern könnt.
Hackern geht es in den seltensten Fällen darum, Inhalte von einer Website zu entwenden. Vielmehr sind private Daten der Besucher interessant oder kompromittiere Websites werden dazu Missbraucht, Spam- und Viren-Mails zu versenden. Auch kann Schadcode direkt in der Website eingebettet werden, der die Besucher beim Aufruf angreift.
Doch: „Wer würde meine Website schon hacken, bei mir gibt es nichts zu holen?“ Dieses Vertrauen auf die eigene „Bedeutungslosigkeit“, der gerade bei Betreibern kleinerer Websites verbreitet ist, ist ebenfalls gefährlich. Denn in der Regel erfolgen Hacking-Attacken auf Websites heutzutage Skript-gesteuert und entsprechende Hacking-Programme durchforsten systematisch das Web. Weit verbreitete Content Management Systeme wie WordPress oder Joomla sind hiervor besonders betroffen. Deshalb ist es wichtig, kritische Sicherheits-Updates zeitnah einzuspielen und auch sonst die ein oder andere Vorkehrung zu treffen.
Zum Thema Joomla-Sicherheit haben wir bereits vor einiger Zeit einen ausführlichen Beitrag hier im Blog veröffentlicht. Dieser beschreibt in Form einer Schritt-für-Schritt Anleitung das Vorgehen bei einem Hacker-Angriff. Heute geht es darum, wie ihr eure über die wp-config.php euer WordPress absichern könnt. Dazu haben wir euch 7 Tipps zusammengestellt.
Bevor ihr beginnt Änderungen in der wp-config.php vorzunehmen, sollte ein Backup dieser Datei lokal auf eurem auf Computer erfolgen. Denn die wp-config.php beeinflusst maßgeblich die Steuerung deiner WordPress-Website. Werden hier ungültige oder fehlerhafte Einträge vorgenommen, wird die Website nicht mehr wie gewohnt funktionieren!
Benutzerdefinierte Änderungen werden in der wp-config.php vor dem Developer-Bereich definiert. So sind sie u.a. auch leicht nachzuvollziehen.
Bei jedem Login auf WordPress werden Informationen über Cookies im Browser gespeichert und zwischengelagert. Die Sicherheitsschlüssel spielen bei der Verschlüsselung der hinterlegten Informationen im Cookie eine große Rolle. Über die Sicherheitsschlüssel soll es Angreifern erschwert werden, Informationen zu manipulieren und dadurch Schaden auf dem System zu nehmen. Bei der Installation werden standardmäßig diese Schlüssel erzeugt. Diese können folgendermaßen aussehen:
Trotz allem kann es nicht schaden diese Sicherheitsschlüssel von WordPress neu generieren zu lassen. Um sich neue Sicherheitsschlüssel generieren zu lassen klickt hier: https://api.wordpress.org/secret-key/1.1/salt/
WordPress bekommt bei der Installation standardmäßig den Datenbank-Präfix „wp_“ zugeordnet. Wenn ihr ein neues WordPress installiert, könnt ihr auch einen individuellen Datenbank-Präfix (Tabellen-Präfix) vergeben wie beispielweise „u2re8_“. Die Wahrscheinlichkeit einer SQL-Injektion lässt sich hiermit weiter verringern.
Soll der Datenbank-Präfix bei einem bereits installierten WordPress geändert werden, ist es etwas komplizierter. Denn wenn ihr den Datenbank-Präfix einfach ändert, kann die Zuordnung der Tabellen in der hinterlegten Datenbank nicht mehr erfolgen. Diese Tabellen mit dem neuen Präfix sind zuerst einmal nicht vorhanden. Wie so oft bei WordPress gibt es aber ein passendes Plugin mit dem Namen „Acunetix WP Security“. Mit Hilfe dieses Plugins kann der Datenbank-Präfix neu vergeben werden. Ein Backup der Datenbank sollte vorher trotzdem erfolgen!
Bei WordPress können über das Backend Änderungen am Quellecode von Plugins und Themes vorgenommen werden. Der Editor dazu findet sich unter Design > Editor oder Plugins > Editor. Sollte ein Hacker Zugriff hierauf erhalten, kann er uneingeschränkt Schadcode und Malware hinterlegen.
Mehr Sicherheit bietet das Deaktivieren des Editors. Änderung an den entsprechenden Dateien können dann immer noch z.B. per (S)FTP direkt auf dem Server erfolgen.
Um den Editor zu deaktivieren muss folgende Codezeile in die wp-config eingefügt werden:
define('DISALLOW_FILE_EDIT', true);
Viele Administratoren nutzen zur Datenübertragung noch das unsichere FTP-Protokoll. Dieses überträgt die Zugangsdaten unverschlüsselt und im Klartext an den Webserver.
Die meisten Webhoster bieten jedoch auch das FTPS bzw. SFTP-Protokoll zur sicheren Datenübertragung an. Mit beiden Protokollen wird der Verbindungsaufbau verschlüsselt und bietet deutlich mehr Sicherheit bei der Datenübertragung. Auch so könnt ihr euer WordPress absichern.
Nutzt ihr FTPS, muss folgende Codezeile in der wp-config ergänzt werden:
define('FTP_SSL', true);
Nutzt ihr SFTP dann definiert ihr dies mit folgendem Eintrag:
define('FTP_SSL', true);
Der Debug-Modus hilft bei der Fehlersuche während der Website-Entwicklung. Er sollte auf dem Live-System jedoch nicht aktiviert sein. Je nach Gegebenheit können nämlich sensible Daten über den Debug-Modus ersichtlich werden, die Hacker bei ihrer Arbeit unterstützen können.
Um den Debug-Modus zu deaktivieren muss folgende Codezeile hinzugefügt werden:
define('WP_DEBUG', false);
Wir hoffen, wir konnten euch mit diesen einfachen Tipps helfen, euer WordPress sicherer zu machen und vor unerwünschten Hacks zu schützen.
Kommentare sind geschlossen.
In Punkt 6 bei: Nutzt ihr FTPS oder SFTP.
Ken Unterschied zwischen den beiden Codezeilen: define(‚FTP_SSL‘, true); ?
Das mit dem Abschalten des Editors (Punkt 5) kannte ich gar nicht und werde ich direkt mal testen. Sehr hilfreich, danke!
Wo genau dürfen bzw. müssen zusätzliche Zeilen eingefügt werden? Meine wp-config.php sieht nämlich völlig anders aus – da gibt es keinen Developers Bereich. Hier ein Beispiel:
<?php
define('FS_METHOD', 'direct');
// ** MySQL settings ** //
/** The name of the database for WordPress */
define('DB_NAME', '');
/** MySQL database username */
define('DB_USER', '');
/** MySQL database password */
define('DB_PASSWORD', '');
/** MySQL hostname */
define('DB_HOST', '');
/** 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', '');
define('AUTH_KEY', ';
define('SECURE_AUTH_KEY', ';
define('LOGGED_IN_KEY', ';
define('NONCE_KEY', '+;
define('AUTH_SALT', ';
define('SECURE_AUTH_SALT', ;
define('LOGGED_IN_SALT', 'W{/S=;
define('NONCE_SALT', ';
$table_prefix = 'qnKTYlqk';
/* That's all, stop editing! Happy blogging. */
/** 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');
Hallo Dominik,
du kannst die weiteren Anweisungen einfach direkt nach dem öffnenden PHP-Tag einbauen, als quasi als erste Anweisung.
Viele Grüße
Sebastian
Cooler Beitrag. Wer sich mit Programmierung auskennt, kann sich mit ein paar einfachen Tricks wirklich gut absichern. Klar, eine 100% Sicherung gibt es nie, aber man kann es ungebetenen Gästen so schwer wie möglich machen 😉