WordPress absichern

• Standardmäßig ist das Tabellenpräfix von WordPress »wp_«. Ihr könnt das Prefix bspw. auf 12eeXk98_wp_ ändern. Damit reduziert ihr die Wahrscheinlichkeit einer SQL-Injections, die gezielt auf das »wp_« Tabellenpräfix ausgerichtet ist. Doch Vorsicht bei diesem Eingriff! Am einfachsten ist es, den Wert noch bei der WordPress-Installation anzupassen. Ansonsten sind später Änderungen in der Datenbank und der »wp-config.php« notwendig.

4.3 Backups

Eure WordPress-Installation wurde von einem Angriff kompromittiert? Ihr habt durch eine kleine Unachtsamkeit wichtige Dateien gelöscht? Ein Plugin hat euch die komplette Webseite zerschossen? Ärgerlich – aber mit einem Backup seid ihr auf der sicheren Seite. Vor jedem Update einer WordPress-Installation und zu festgelegten Zeitpunkten sollten Backups durchgeführt werden. Dazu eignet sich zum Beispiel das Plugin BackUpWordPress oder BackWPup-Plugin. Neben den Seiten, den Konfigurationsdateien, Themes und Plugins wird ebenfalls ein Backup von der Datenbank erstellt.

Backups sind Pflicht! Nach jedem Backup-Durchlauf solltet ihr euch die Daten auf euren Rechner herunterladen und dort sicher verwahren.

4.4 TLS-Verschlüsselung (ehemals SSL)

Es existieren verschiedene Arten von TLS-Zertifikaten. Ein TLS-Zertifikat bzw. die TLS-Verschlüsselung ermöglicht eine verschlüsselte Kommunikation zwischen WordPress und eurem Browser – Passwörter für die Anmeldung im Dashboard lassen sich somit nicht von einem Angreifer mitlesen. Falls euer Anbieter bzw. Hoster TLS-Zertifikate unterstützt, solltet ihr eines beantragen. Je nach Vertragsdauer belaufen sich die Kosten auf ca. 25 – 60 € pro Jahr für eine Domain. Alternativ könnt ihr bei Let’s Encrypt ein kostenloses Zertifikat beantragen – falls dies bei eurem Hoster möglich ist, dann solltet ihr diese Variante wählen.

Um sicherzustellen, dass eure Kommunikation nach der Integration eines TLS-Zertfikats verschlüsselt stattfindet, solltet ihr in der Datei »wp-config.php« folgende Änderung vornehmen:

define('FORCE_SSL_ADMIN', true);

Mit »FORCE_SSL_ADMIN = true« wird neben dem Anmeldeprozess die gesamte Admin-Session verschlüsselt. Dazu zählen neben dem Passwort für die Anmeldung auch die Cookies. Seit WordPress 4.x ist der Paramater »FORCE_SSL_LOGIN = true« übrigens veraltet und wird vollständig durch »FORCE_SSL_ADMIN = true« ersetzt.

3. Howto: Apache .htaccess

Solltet ihr nicht über einen eigenen Server verfügen ist die Wahrscheinlichkeit hoch, dass euer Webhoster auf Apache zurückgreift. Mindestvoraussetzung für die Anleitung ist eine Hosting-Umgebung bei der Zugriff auf das Webverzeichnis besteht. Dann könnt ihr im Normalfall .htaccess Dateien verwenden, um diverse Schutzmaßnahmen zu implementieren. Für den Schutz des Login-Bereichs sind folgende Schritte notwendig:

• Zunächst wird im Hauptverzeichnis eures Blogs eine Datei mit dem Namen ».htpasswd« angelegt.
• Anschließend wird die ».htpasswd« Datei mit Inhalt gefüllt. Nutzt dazu den .htpasswd Generator. Wählt einen Usernamen und ein sicheres Passwort (bspw. 20 Zeichen). Als Hashing-Verfahren selektiert ihr »bcrypt« mit einer Cost von »11«. Die Ausgabe des Generators kopiert ihr anschließend in die eben angelegte ».htpasswd« und speichert die Datei ab.
• Ebenfalls im Hauptverzeichnis legt ihr eine weitere Datei mit dem Namen ».htaccess« an (eventuell ist diese auch schon vorhanden, dann ergänzt ihr sie). Kopiert das untenstehende Code-Snippet und fügt es hinter »# END WordPress«  in die Datei ein.
• Wichtig: Anschließend müsst ihr noch den genauen Pfad zur User- bzw. Passwortdatei ».htpasswd« unter AuthUserFile anpassen. Falls ihr damit Probleme habt könnt ihr den Pfad mit dem PHP-Schnipsel ermitteln. Wird der Pfad falsch gesetzt, kommt es bspw. zum Internal Server Error 500 oder ähnliches.

3.1 Apache Code-Snippet

Hinweis: Beachtet die Änderungen ab dem Apache 2.4.

# Bis einschließlich Apache 2.3
# Auth protect wp-login.php
<Files wp-login.php>
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /pfad/zur/.htpasswd
   Require valid-user
</Files>
# Deny access to important files
<FilesMatch "(\.htaccess|\.htpasswd)">
   Order deny,allow
   Deny from all
</FilesMatch>

# Ab Apache 2.4
# Auth protect wp-login.php
<Files wp-login.php>
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /pfad/zur/.htpasswd
   Require valid-user
</Files>
# Deny access to important files
<FilesMatch "(\.htaccess|\.htpasswd)">
   Require all denied
</FilesMatch>

Code-Snippet kurz erklärt:

• Files: Unter Files wird die zu schützende Datei definiert. Erst nach einer erfolgreichen Authentifizierung gegenüber dem Webserver kann die »wp-login.php« aufgerufen werden.
• AuthType: Mit AuthType Basic wird die Authentifizierungsmethode gegenüber dem Webserver definiert. Bei dieser Methode wird der Username und Passwort unverschlüsselt übertragen – daher solltet ihr den Admin-Bereich immer über eine TLS-verschlüsselte Verbindung aufrufen. Ansonsten könnte jemand die Anmeldedaten mitschneiden. Im zweiten Teil der Artikelserie habe ich das bereits kurz erläutert.
• AuthName: Der AuthName legt fest wie der geschützte Bereich heißen soll.
• AuthUserFile: Unter AuthUserFile wird der Pfad zur ».htpasswd« festgelegt.
• require: Jeder User (valid-user) der in der ».htpasswd« definiert wurde erhält nach Eingabe des korrekten Passworts Zugang zur »Restricted Admin-Area«.
• FilesMatch: Unter FilesMatch verbieten wird jeglichen Zugriff von außen auf die soeben angelegten Dateien ».htaccess« und ».htpasswd«. Eine Vorsichtssmaßnahme, damit keiner deren Inhalt auslesen kann.

4. Directory Browsing unterbinden

Standardmäßig sollte das Directory Browsing aus Sicherheitsgründen ausgeschaltet sein. Es ermöglicht die automatische Ausgabe eines Inhaltsverzeichnisses von Dateien und Ordnern auf dem Webspace. Da WordPress weit verbreitet ist kennen viele die Dateistruktur und verschaffen sich durch Aufrufe wie »www.domain.de/wp-content/plugins« einen Einblick in die verwendeten Plugins – Directory Browsing gilt es daher zu deaktivieren.

4.1 Apache

# Prevent Directory Listings
Options -Indexes

Die Modifikation ist in der .htaccess Datei im Root-Verzeichnis von WordPress durchzuführen.

6. Admin Zugang auf IP-Adresse beschränken

Im Beitrag .htaccess Schutz – WordPress absichern Teil4 habe ich euch vorgestellt, wie der Admin-Bereich von WordPress mit einem Zugriffsschutz abgesichert werden kann. Durch die Limitierung auf eine IP-Adresse wird der Zugangsbereich zusätzlich geschützt – Zugriff erhalten dann lediglich autorisierte IP-Adressen. Problematisch wird es bei ständig wechselnden IP-Adressen, aber auch hierfür gibt es eine Lösung. Apache kann IP-Adressen über ihren Domain Namen auflösen.

Einfaches Beispiel:
Mit dem ping, dig oder host Befehl könnt ihr die IP-Adresse zum jeweiligen Domain Namen herausfinden. Ein ping auf web.de:

Die Domain web.de löst also auf die IP-Adresse 212.227.222.8 auf. Eine Anfrage auf einen Domain Namen funktioniert damit ähnlich einer Telefonauskunft.

Mittels Dynamic DNS lässt sich das Problem der ständig wechselnden IP-Adresse lösen. Dadurch wird der Rechner immer über den selben Domainnamen erreichbar bzw. Apache führt ein DNS Lookup durch und erhält die dazugehörige IP-Adresse. Über eine FRITZ!Box könnt ihr euch recht fix ein Dynamic DNS Eintrag einrichten. Dazu hatte ich einen Artikel (Fritzbox 6360 Dynamic DNS mit Two DNS als Anbieter) verfasst, der sich im speziellen mit dem Anbieter TwoDNS befasst.

6.1 Apache

# Bis einschließlich Apache 2.3
# Protect wp-login.php
<Files wp-login.php>
   Order deny,allow
   Deny from all
   Allow from [DYNAMIC.DNS.NAME]
</Files>

# Ab Apache 2.4
# Protect wp-login.php
<Files wp-login.php>
   Require host example.org
</Files>

[DYNAMIC.DNS.NAME] dient als Platzhalter für den Domain Namen, den ihr beim Dynamic DNS Anbieter registriert habt. Die Modifikation ist in der .htaccess Datei im Root-Verzeichnis von WordPress durchzuführen.

Ihr könnt das Code-Snippet auch mit dem Zugriffsschutz kombinieren:

# Bis einschließlich Apache 2.3
# Protect wp-login.php
<Files wp-login.php>
   Order deny,allow
   Deny from all
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /pfad/zur/.htpasswd
   Require valid-user 
   Allow from [DYNAMIC.DNS.NAME] 
</Files>

# Ab Apache 2.4
# Protect wp-login.php
<Files wp-login.php> 
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /pfad/zur/.htpasswd
   Require valid-user 
   Require host example.org
</Files>

7. Direkte Ausführung von PHP-Dateien unterbinden

Oftmals ist der Uploads Ordner unter »/wp-content/uploads« ein beliebtes Einfallstor für Angreifer, da dieser in den meisten Fällen beschreibbar sein muss. Mit cleveren Tricks oder unter Ausnutzung von Sicherheitslücken (bspw. WordPress Asset-Manager PHP File Upload Vulnerability, WordPress File Uploader Plugin PHP File Upload Vulnerability) werden PHP-Dateien in Verzeichnisse geladen und dort dann ausgeführt. Eine direkte Ausführung von PHP-Dateien in den Unterordnern »/wp-content« oder »/wp-includes« kann dieses Angriffsszenario begünstigen und sollte daher mit Code-Snippets vermieden werden.

Vorsichtig: Je nach Theme, verwendete Plugins oder selbstgeschriebene Erweiterungen können die Code-Snippets bestimmte Funktionen stören. Im Zweifelsfall sollte zumindest die PHP-Ausführung im Unterordner »/wp-content/uploads« deaktiviert werden.

7.1 Apache

# Bis einschließlich Apache 2.3
# Disable direct access of any *.php files in /wp_content folder
<FilesMatch \.php$>
   Order deny,allow
   Deny from all
</FilesMatch>

# Ab Apache 2.4
# Disable direct access of any *.php files in /wp_content folder
<FilesMatch \.php$>
   Require all denied
</FilesMatch>

Die Modifikation ist in der .htaccess Datei im »/wp-content« von WordPress durchzuführen.

# Bis einschließlich Apache 2.3
# Disable direct access of any *.php files in /wp_includes folder
<FilesMatch (?<!wp-tinymce)\.php$>
   Order deny,allow
   Deny from all
</FilesMatch>

# Ab Apache 2.4
# Disable direct access of any *.php files in /wp_includes folder
<FilesMatch (?<!wp-tinymce)\.php$>
   Require all denied
</FilesMatch>

Die Modifikation ist in der .htaccess Datei im »/wp-includes« von WordPress durchzuführen.

Falls die Anpassung aufgrund von Plugins oder Modifikationen nicht funktioniert, dann legt zumindest in »/wp-content/uploads« eine .htaccess Datei mit folgendem Inhalt an:

# Bis einschließlich Apache 2.3
# Disable direct access of any *.php files in /wp_content/uploads folder
<FilesMatch \.php$>
   Order deny,allow
   Deny from all
</FilesMatch>

# Ab Apache 2.4
# Disable direct access of any *.php files in /wp_content/uploads folder
<FilesMatch \.php$>
   Require all denied
</FilesMatch>

Wie deaktiviere ich die XML-RPC-Schnittstelle in WordPress?

add_filter( 'xmlrpc_enabled', '__return_false' );

add_filter( 'wp_headers', 'remove_pingback' );
 function remove_pingback( $headers )
 {
 unset( $headers['X-Pingback'] );
 return $headers;
 }

<Files xmlrpc.php>
 Order Deny,Allow
 Deny from all
 </Files>