Ich bin sicher nicht der super WordPress-Freak und auch kein Web-Developer – jedoch genug IT-Experte und auch professioneller Anwender, so das ich das Sicherheits 1*1 verstehe. Der nachfolgende Text ist also von einem ‘normalen’ WP-Admin & Blogger für genau so welche die es werden wollen gedacht – ohne viel BlahBlah und auch ohne Einführung das es ganz wichtig ist ‘sichere’ Passwörter zu nutzen, etc. pp.

Grundsätzliches zur Sicherheit

Die weite Verbreitung, viele Plugins & Themes nachen WordPress (WP) für viele Anwender (und Hacker) interessant – jedoch stellt jedes Plugin (und die eventuell enthaltenen Fehler und Hintertüren) ein Sicherheitsrisiko dar – genau wie ggf. nachlässig programmierte oder gewartete Themes. Wer meinen kürzlich erschienenen Blogpost zu Firefox gelesen hat wird sich erinnern – denn da gilt gleiches.

Ein weiterer Punkt beim Betrieb einer WP-Installation sind die verwendete Version von PHP, dem WebServer, der Datenbank und dem unterliegenden Betriebssystem – auch hier müssen (neben einer aktuellen WP-Version) immer die neusten Bugfixes eingespielt werden. Am besten überlässt man das einem Web-Hoster, der automatisch dafür sorgt. So ist dieses Blog z.B. mit einem einfachen PowerWeb Paket bei Strato gehostet – das klappt ab 4€/Monat inkl. einer Domain und HTTPS Zertifikat -> das letztere ist sehr wichtig, damit die Login-Daten richtig verschlüsselt werden!

Zusammenfassend:

• So wenig Plugins wie möglich installieren.
  • Diese sollten dann auch (vom Anbieter) regelmäßig gepflegt werden und
  • eine große Installationsbasis haben.
  • Nicht verwendete Plugins löschen.
• Das verwendete Theme sollte kein Exot und auch aktuell sein.
  • Nur das genutzte Theme installiert lassen.
• WP immer aktuell halten.
  • Ganz wichtig: Auch die Plugins (weiter unten mehr dazu).
  • Denn sofort dach dem veröffentlichen einer neuen Version ist allen (bösen Buben) klar, wie sie die Fehler ggf. ausnutzen können!
• Am besten ein WP-Hostingpaket nutzen
  • So das man sich nicht um die Updates von MySQL, Server und PHP kümmern muss.
  • Unbedingt SSL (‘https’) aktivieren!

Vorab: Administrator- und Autorenrollen trennen!

Wenn WP installiert wird braucht es einen Administrator. Dieser sollte auf keinen Fall ‘admin’, ‘wordpress’, ‘administrator’ o.ä. benannt werden. Denn dies sind die Standard-Login Namen mit denen versucht wird Passwort-Attacken zu machen (ja, das ist wirklich ein Problem!).

Ganz wichtig: Weil der Name des Autors eines Blogposts in der URL steht sollte mit dem richtigen ‘Admin’-Account auch nie ein Blogpost verfasst werden. Der Admin-Account sollte nur für die Wartung, zum Einrichten von Benutzern, der Installation von Plugins, etc. dienen. Nur mit einem zweiten Account der (nur) die Rechte eines ‘Autors’ hat – sollten dann Blogposts verfasst werden.

WP Security

Ein meiner Ansicht nach sehr gutes Sicherheits-Plugin ist WP Security mit (zu Recht) ca. 3,2 Millionen Downloads. Dieses Plugin bietet u.a. folgende Funktionen an:

• Einfacher Login-Schutz (‘Login-Logdown’ unter User-Login)
  • Bei mehrfacher Passwort-Fehleingabe (z.B. 3) wird eine IP-Adresse x Minuten für weitere Versuche gesperrt.
  • Dieses verhindert ‘Brute-Force’ Passwort-Attacken auf User-Logins.
• Cookie-Basierender Login-Schutz (‘Cookie Based Brute Force Prevention’ unter Brute Force)
  • Normal kann sich ein Nutzer unter der Adresse https://blogname.domain/wp-login.php einloggen – das nutzen auch die Angreifer aus.
  • Mit diesem Schutz kann man nun eine eigene URL festlegen (z.B. https://blogname.domain/?blahblubber=1). Unter dieser URL wird dann ein Session-Cookie im Browser abgelegt – und nur wenn dieses vorhanden ist, kann auf die normale wp-login.php zugegriffen werden.

Werden diese beiden Funktionen kombiniert – u.a. für Blogs mit nur einem bzw. sehr wenigen Autoren – dann sollten faktisch alle Passwort-Attacken ins leere laufen.

Weitere Wichtige Funktionen beziehen sich auf die Zugriff im Datensystem und auf dem Web-Server. In diesem Kontext fand ich folgende Funktuionen (unter ‘Filesystem Security’)  sehr wichtig:

• Datei-Berechtigungen (‘File Permissions’)
  • Stattet Datei- und Verzeichnisse auf dem Server mit möglichst restriktiven Rechten aus.
• Zugriff auf Standard-Dateien (‘WP File access’)
  • Verhindert Zugriff auf einige Standard-Dateien von WP-Installationen (über die ggf,. einige Details wie Versionsinformationen zu erfahren sind).

Diese Einstellungen empfinde ich als sehr wichtig – weil es sein kann, das verschiedene Plugins die Dateirechte ggf. in einen unsicheren Zustand modifizieren. Mit WP-Security lässt sich hier sehr einfach prüfen ob soweit noch alles o.k. ist.

Im nächsten Schritt bietet WP-Security dann unter ‘Firewall’ noch weitere wichtige Möglichkeiten einen Missbrauch des Blogs zu vermeiden:

• Basic Firewall Settings
  • Schützt die .htaccess und wp-config Datei (Sicherheitsrelevante Einstellungen)
  • Begrenzt Uploads auf 10 MB, etc.
• Deaktivierung der XML-RPC Schnittstelle und Zugriff auf das Debug-Logfile
  • Gerade die XML-RPC Schnittstelle halte ich für eine große potentielle Angriffslücke. Ein einfaches Blog wird diese Schnittstelle denn auch nicht benötigen.
• Zugriff auf Verzeichnisse und andere Angriffe (XSS, Proxy, Track & Trace)
  • können dann unter ‘Aditional Firewall  Rules’ aktiviert werden
• 404 Erkennung und Lockout
  • Viele Angreifer versuchen mit dem Zugriff auf bestimmte (geratenen) URLs zu prüfen ob bestimmte (verwundbare) Plugins installiert sind.
  • Mit dieser Einstellung werden potentielle Angreifer-IP Adressen (temporär) gesperrt – wenn diese mehr als 3 Seiten aufrufen (wollen) die es gar nicht gibt.
• Prevent Hotlinks
  • Wer nicht mag das Bilder von der eigenen Seite irgendwo direkt verlinkt bzw. eingebettet werden (kostet Server-Ressourcen) – der aktiviert diese Option.

Um den anonymen Zugriff auf Nutzerdaten zu verhindern, sollte dann auch noch unter ‘Miscellaneous’ (Verschiedenes) der Zugriff auf die ‘Users Enumeration’ beschränkt werden.

Eine letzte wichtige Einstellung wäre dann noch den Datenbank-Prefix (‘wp_’) von WordPress zu ändern. Dies verhindert, das bestimmte Attacken (u.a. SQL-Injection) gegen WP durchgeführt werden können. WP-Security bietet auch hier eine automatische Funktion um dies durchführen zu können (unter ‘Database Security’). Für diese Änderung ist es jedoch sinnvoll die gesamte WP-Installation vorab zu sichern – falls etwas schief gehen sollte. Natürlich sollte man auch in der Lage sein die Sicherung wieder zurück zu spielen 🙂

Backup der WP-Installation (mit Datenbank, & Co.)

Ganz wichtig: Immer schön Backups machen! Im Falle das die eigenen WP-Seite doch gehackt wird, der Provider die Daten verliert, die Datenbank einen Fehler hat, ein WP- oder Plugin Update danebengeht, etc. pp.

Bei meinem Provider Strato gibt es je nach Paket eine manuelle oder automatische Option die gesamte WP-Installation zu backuppen – und aus einem Backup wieder her zu stellen. Zusätzlich können sich hier jedoch auch Plugins wie Updraft Plus anbieten. In Updraft Plus kann man angeben wie oft man die Sicherung ausführen möchte, wie viele Sicherungen aufgehoben werden sollen – und wo man die Sicherungen ggf. speichern möchte (lokaler Server, externer Web-Space, DropBox, etc. pp). Wer nur lokal sichert muss jedoch die Backups ab und zu noch lokal auf seinem Rechner (oder anderweitig) sichern – also mit SSH (z.B. WinSCP) auf dem Server einloggen un die Dateien dann manuell kopieren (die Dateien liegen dann unter /wp-verzeichnis/wp-content/updraft).

Wichtig beim Backuppen ist auch – (irgendwann) rauszufinden bzw. zu lesen wie man eine Sicherung wieder zurückspielt und hier insbesondere die Datenbank wieder herstellt. Meistens stellen dafür die Provider (z.B. Strato) verschiedene Tools bereit – in denen man nur ‘Backup’ oder ‘Wiederherstellung’ clicken muss. Möchte man hingegen Backups von Updraft wiederherstellen, dann braucht man nur den Button ‘Wiederherstellen’ zu wählen und muss das zu wiederherstellende Backup wählen. Letzteres funktioniert natürlich nur, wenn die WP-Installation noch läuft -> ansonsten braucht man Zugriff auf die Datenbank (z.B. per Web-Oberfläche) und Zugriff auf die Installationsverzeichnisse des WebServers (z.B. via SCP bzw. FTP) um die Dateien ‘per Hand’ zurückzuspielen.

Einige weitere Tips zur wp-config.php

In der wp-config.php sind noch einige wichtige Einstellungen vornehmbar. Diese Datei liegt in der WordPress Installation auf dem WebServer und kann z.B. mit WinScp (SSH/SCP-Client) modifiziert werden, wenn direkt auf die Installation auf dem Server zugegriffen wird. Alternativ kann auch mit dem WP- Security Plugin unter ‘Settings/wp-config.php File’ die Datei auf den PC geladen, dann geändert – und wieder zurückgespielt werden.

In der Datei können u.a. vier Dinge geändert werden. Zuerst gibt es dort einen Ausschnitt der so aussieht:

define('AUTH_KEY',         'z>3@vr=]I+$E]eWkYx5-yW4>CZdD*$Oh-GqMH^YTGk@9AK=^aa5R)-UhdD|g!IjJ');
define('SECURE_AUTH_KEY',  'N8B0E8!f?Hkk&.<yVg3}=u2^RavlE.7E-zm~M3@HVh<TY!uq!O:(+.[0Dy`_88!y');
define('LOGGED_IN_KEY',    'gY7EvVv@Hj+w_SWoJBl$Eij)9|+i+@^Zb{C[@cIGT e?x_y|j,N5u4y$xV)bL7Fa');
define('NONCE_KEY',        'foH5+owmJFnnB.9R>!|H6OE8B> dkfyd%BIA[gvjnAT.fwD:W+R&HiiO.pbdOayN');
define('AUTH_SALT',        '=Z#8WS 9J/~<wxxg4B!bg%uA06mOzJYh|4HS1Pm#f{V-+*+%ARsQ.BSNTpt+eKV4');
define('SECURE_AUTH_SALT', '^u|xHs{$@cQ;NTflX%+j)!<-zf3.,{.{Nz^+Ccb~W 2cWaSv8N8&d|c,L-oxK%*(');
define('LOGGED_IN_SALT',   '-JxHs<E8%5Cdo5}]^/jldmyRE-Sd2RJix+28LfI,TGjo/dN_?.XC]:}822KpU ny');
define('NONCE_SALT',       '|rur)B:JxDfK6+KZXc9-Fz/``Y@xveH+Jzxn+@vJ@9Tr#~~j?D~]r!vxt|H-Q)n{');

 

Dies sind die Grundwerte für die Generierung von Verschlüsselungen. Unter der URL: https://api.wordpress.org/secret-key/1.1/salt/ (einfach eingeben bzw. Clicken) kann man sich eigene Zufallswerte generieren lassen – und diese dann in die wp-config.php übernehmen (um die Standardwerte zu überschreiben).

Die zweite Sache ist die Einstellung zum automatischen Updaten der WP-Installation in der wp-config.php. Dort ist eine Zeile die folgend aussieht:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Wenn das “true” am Ende gegen ein “false” ausgetauscht wird – werden die automatischen Update aktiviert. Wenn man nicht möchte, das WP alles aktualisiert – also Plugins, Themes, die Grundinstallation und Sprachdateien, dann kann man das ganze einschränken in dem man z.B. nur kleinere Updates der WP-Installation zulässt – und den Rest dann selber immer noch ‘per Hand’ anstößt. Folgende Zeile muss dafür in die wp-config.php eingefügt werden:

define( 'WP_AUTO_UPDATE_CORE', minor );

Wer dann kein WP-Entwickler ist, der sollte das Editieren von Theme-Dateien & Co. in WP abstellen – insb. wenn auch andere Benutzer als man selber Adminrechte haben. Es verhindert jedoch auch das unbemerkte Verändern der WP-Installation – falls diese doch mal gehackt werden sollte:

define('DISALLOW_FILE_EDIT', true);

Mit einer letzten Einstellung kann man noch erwirken, das sich Admins nur über HTTPS einloggen können – soweit HTTPS für die eigene Domain verfügbar bzw. aktiviert ist:

define('FORCE_SSL_ADMIN', true);

Ich habe nicht gesucht ob diese Sachen auch durch Plugins vorgenommen werden können – sicherlich. Nur bin ich bei der Verwendung von Plugins sehr Sparsam!

Das wars schon!

Mehr möchte ich hier gar nicht schreiben – denn ich denke mit den präsentierten Strategien:

• Wenige Plugins & Themes,
• einen WP-Hoster mit automatischen Updates (DB, Server, PHP),
• dem WP Security Plugin in Punkto:
  • User-Login Optionen (Sperrung nach 3 Versuchen, Cookie Basierte Authentifikation)
  • Dateisystem-Berechtigungen (Überprüfung)
  • Firewall (Schutz der Verzeichnisse,der .htaccess & wp-config.php Dateien vor dem Auslesen)
  • und ggf. einer Datenbank-Prefix Änderung,
• sowie einem (automatischen) Backup (seitens des Hosters oder mit Plugins wie Updraft)

sollten die meisten einfachen WP-Blogger recht gut fahren.