Wordpress-Security Checkliste

Wordpress hat unter den Content Management System im Internet mittlerweile einen Marktanteil von 60% erreicht und lockt mit dieser Verbreitung natürlich auch kriminelle Geister an und so schwirren immer wieder Nachrichten über Sicherheitslücken und gehackte WP-Seiten durch die einschlägigen Medien. Aus diesem Grund will ich mal meine Erfahrungen in Bezug auf Wordpress-Sicherheit an dieser Stelle zusammenfassen und zwar so kompakt wie möglich, damit diese Information als Checkliste genutzt werden kann.

Wenn du Betreiber einer Wordpress-Seite bist, gibt es dafür drei Wege und unterschiedliche Freiheiten, sich selber um die Sicherheit der WP-Installation zu nutzen - im folgenden die “Freiheitsgrade” genannt: Bei “wordpress as a service” greifst du auf einen Angebot zurück, das bekannteste ist wordpress.com, bei dem du nur Zugriff auf das Backend hast und dementsprechend wenig Konfigurationsmöglichkeiten. Als Nutzer eines Shared Hosting hast du zusätzlich die Möglichkeit, per FTP oder SSH auf den Webspace zu gelangen und dort Einstellungen vorzunehmen. Und schließlich gibt es noch die Möglichkeit, einen eigenen Server zu nutzen, bei dem du dich auch um die Konfiguration auf Systemebene, also des Webserver kümmern musst. In dieser Reihenfolge möchte ich nun im folgenden Zusammenfassen, welche Möglichkeiten du hast, deine WP-Installation etwas sicherer zu gestalten.

Aktuelle Updates

Zunächst zum Offensichtlichen: Sicherheitsupdates. Die automatischen Updates des WP-Cores (also dem, was WP ausmacht) sind mit jedem Freiheitsgrad konfigurierbar, bergen aber auch Risikos. So hatte z.B. das Update auf Version 4.9.3 Anfang 2018 den Auto-Update-Mechanismus deaktiviert. Spätere Sicherheitsupdates würden also ignoriert werden. Grundsätzlich ist das Auto-Update nur für sog. Minor-Versionen zu empfehlen, wodurch Sicherheitlücken und Bugs behoben werden. Wer diese Funktion auf einem Test-System auch für Major-Versionen aktivieren möchte, muss in der wp-config.php folgenden Parameter setzen:

define( 'WP_AUTO_UPDATE_CORE', 'true' );

(der Parameter ist per default auf minor gesetzt.) Grundsätzlich ist das aber nicht zu empfehlen: Denn: Bevor ein großes Update eingespielt wird, sollte das auf Herz & Nieren und natürlich Kompatibilität mit den vorhandenen Themes und Plugins getestet werden. Dazu sollte man ein Staging-System einrichten, worauf ich im nächsten Absatz eingehe.

Ein Staging-System nutzen

Die Sicherheit der WP-Installation kann nicht nur durch Malware oder Angriffe von außen versehrt werden, sondern auch durch Bedienfehler. Ein wichtiger Baustein ist also ein Staging-System. Das ist im weitesten Sinne eine exakte Kopie der aktuelle WP-Installation. Das Staging-System erfüllt eine Reihe von Funktionen:

  • Testen von Plugins & Updates auf Kompatibilität
  • Referenz-System zum Erkennen von verdächtigen Änderungen
  • Testen von Änderungen am Theme

Wie ein Staging-System eingerichtet wird, habe ich hier genauer erklärt. Was es mit dem 2. Punkt auf sich hat, erkläre ich weiter unten.

Regelmäßige Backups

Auch Backups sind ein wichtiger Teil eines Sicherheitskonzeptes. Hier gibt es je nach  Freiheitsgrad verschiedene Möglichkeiten. Als Plugin empfehle ich zunächst das sehr weit verbreitete Updraft. Das Backup sollte unbedingt auf einen anderen Ort kopiert werden. Updraft unterstützt in der kostenlosen Version z.B. FTP. Wer kein Problem mit Dropbox oder Google Drive hat, kann natürlich auch die Cloud nutzen. Updraft unterstützt die Verschlüsselung der Datenbank-Sicherung nur in der bezahlten Version. Wer mit personenbezogenen Daten hantiert, sollte sich diese Funktion unbedingt zulegen!

Eine bessere Alternative, die aber nur ab dem 2. Freiheitsgrad möglich ist, ist das Backup über die Kommandozeile. Das ist vor allem dann unumgänglich, wenn die WP-Installation sehr groß ist und nicht mehr mit den gängigen Plugins durchführbar ist. Außerdem funktioniert das unabhängig von Wordpress und kann demnach auch nicht durch andere Plugins beeinträchtigt werden. Wie genau man das einrichtet und vor allem auch die Wiederherstellung habe ich in diesem Beitrag genauer beschrieben.

Plugin-Sparsamkeit

Hierunter ist eher ein Konzept als eine konkrete Handlungsempfehlung zu verstehen. Vor allem technisch unbedarfte Nutzer tendieren dazu, sofort ein Plugin zu installieren, wenn eine bestimmte Funktion benötigt wird. Doch gerade unsaubere, nicht gepflegte Plugins bieten eine Angriffsfläche und noch dazu wirkt sich ein zunehmendes Plugin-Portfolio negativ auf die Performance aus. Wer ein Plugin installieren möchte, sollte dazu nur auf vertrauenswürdige und bekannte Quellen zurückgreifen. Im Klartext: https://de.wordpress.org/plugins/

Die offensichtlichen

  1. Admin-Benutzer umbenennen

Die technischen

  1. Admin-Bereich mit .htaccess schützen
  2. Dateirechte korrekt setzen
  3. PHP-Ausführung in bestimmten Unterordner deaktivieren

Plugins und Themes

Ein zentrales Element und der größte Vorteil von Wordpress ist seine fast unerreichbar funktionale Erweiterbarkeit und sehr große Community. Das zieht allerdings auch schwarze Schafe an.

  1. Installiere nicht wahllos Plugins, weil du eine bestimmte Funktion benötigst
  2. Installiere Plugins nur von vertrauenswürdigen Quellen
  3. Räume deinen Plugin-Ordner regelmäßig auf

Die mutigen

PHP ini-Parameter

Es dürfte kein Geheimnis sein, dass PHP über die php.ini gesteuert wird. Es gibt allerdings einige sicherheitsrelevante Parameter, um die man sich allerdings selber kümmern muss. Die wichtigsten möchte ich hier vorstellen.

Um die Übersicht über manuelle Änderungen nicht zu  verlieren, solltest du die Einstellungen in einer separaten Datei (z.B. security.ini) speichern. Auf der Kommandozeile zeigt dir der folgende Befehl, aus welchem zusätzlichen Ordner PHP zusätzliche ini-Dateien liest:

php --ini

In den meisten Fällen dürfte das /etc/php/7.1/apache2/conf.d/

Eine einfache aber sehr wirksame Maßnahme ist das deaktivieren potentiell gefährlicher PHP-Funktionen. Wie z.B. shell_exec() - im Wordpress-Umfeld gibt es kaum ein Szenario, in dem diese Funktion nützlich sein könnte.  Um PHP-Funktionen zu deaktivieren, kannst du den ini-Parameter disable_functions nutzen.

Dort legst du die security.ini ab und füllst sie entsprechend:

https://www.damianschwyrz.de/php-backdoors-und-shells-finden-eine-kurze-anleitung

siehe auch

https://binary-butterfly.de/artikel/wordpress-login-security-eine-stahltuer-in-der-wellblechhuette/

IP-Filter

Den Admin-Bereich verstecken

<IfModule mod_rewrite.c> RewriteEngine on RewriteBase / # Move Wordpress login to /cms. RewriteRule ^cms wp-login.php?cms=unlocked [L] RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ RewriteCond %{QUERY_STRING} !^cms=unlocked RewriteCond %{QUERY_STRING} !^action=logout RewriteCond %{QUERY_STRING} !^loggedout=true RewriteCond %{REQUEST_METHOD} !POST RewriteRule ^(.*)$ - [R=403,L]

RewriteCond %{REQUEST\_URI} ^(.\*)?wp-login\\.php(.\*)$
RewriteCond %{QUERY\_STRING} ^loggedout=true
RewriteRule ^(.\*) ./cms? \[R=302,NC,L\]

RewriteCond %{REQUEST\_URI} ^(.\*)?wp-login\\.php(.\*)$
RewriteCond %{HTTP\_REFERER} !cms$
RewriteCond %{REQUEST\_METHOD} POST
RewriteRule ^(.\*)$ - \[R=403,L\]

https://wordpress.stackexchange.com/a/292691/132138

Die unnötigen

Sicherheits-Plugins

siehe auch

https://www.kuketz-blog.de/basisschutz-wordpress-absichern-teil1

https://fastwp.de/487

chown user:user -R *
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

chown www-data:www-data wp-content

## Disable Editing in Dashboard
define('DISALLOW_FILE_EDIT', true);

<Directory /var/www/nickyreinert.de/www>
# prevent   var_dump(scandir('/etc'));
# see http://php.net/manual/de/ini.core.php#ini.open-basedir
# alternativ: php für jeden virtuellen host mit separatem user ausführen und die dateirechte anpassen
php_admin_value open_basedir "/var/www/nickyreinert.de/www"

</Directory>

# disable_functions in php.ini
# list of function to disable globally #
disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

PHP-FPM?

Normalerweise ruft der Apache-Webserver den PHP-Interpreter jedes mal erneut auf. Der Nachteil: Viel Speicehrverbruahc, lange Ladezeiten und ein globaler Benutzer. Etwas schneller ist FastCGI. Dabei läuft der Interpreter permanent im Hintergrund. FPM startet nicht nur einen sondern mehrere PHP-Prozesse im Hintergrund.

 

 

//

 

https://stackoverflow.com/questions/45152483/php-fpm-open-basedir-vs-chroot

next →