Posted on 3 Kommentare

WordPress-Sicherheit #2 – Erste Konfiguration

Nachdem wir nun bereits wissen, was man bereits vor der Installation von WordPress alles beachten kann, um seine Website abzusichern, geht es nun mit der Konfiguration direkt bei bzw. unmittelbar nach der Installation weiter.

Egal, ob die Installation im Browser oder manuell über die Bearbeitung der wp-config.php vonstatten geht, letztere muss für die nachfolgenden Tipps zusätzlich bearbeitet werden.

Bestimmte Benutzernamen vermeiden

In der Informationstechnologie gibt es bei den verschiedensten Programmen und Diensten unterschiedliche Standard-Benutzernamen wie „admin“ oder „root“, welche zu Beginn irgendwann einmal automatisch vergeben wurden, bis man sich selbst ein Benutzerkonto einrichtet. Da es hierfür, ebenso wie für Passwörter, mittlerweile sogenannte „Rainbow“-Tabellen gibt, die bei Angriffen automatisch der Reihe nach ausprobiert werden, empfiehlt es sich, möglichst Benutzernamen zu vergeben, die darin nicht vorkommen.

Dazu muss man diese „Rainbow“-Tabellen natürlich nicht kennen. Eine Möglichkeit wäre zum Beispiel die Kombination des eigenen Spitznamens mit dem Projektnamen. In meinem Falle wäre das „Matze“ zusammen mit „KittPress“. Um es noch unwahrscheinlicher zu machen, dass der Benutzername einfach erraten wird, nehme ich nur einen Teil des Projektnamens. Das Ergebnis wäre dann hier „MatzePress“. So muss auch erst einmal der Name herausgefunden werden und nicht nur das Passwort. Außerdem schützt man sich vor solchen oben genannten automatisierten Angriffen.

Datei-Editor deaktivieren

Standardmäßig besitzt WordPress die Möglichkeit, sämtliche Dateien von Themes und Plugins direkt über das Backend zu verändern. Neben diverser Probleme bei Updates oder auch der Möglichkeit, sich seine gesamte Seite abschießen zu können, ist dieser Editor auch sicherheitsrelevant. Denn wenn er aktiviert ist und sich jemand Zugang zum Backend verschafft, hat er die Möglichkeit, ohne Zugangsdaten per (S)FTP oder der Datenbank Inhalte zu verändern und insbesondere Schadcode einzuschleusen. Daher sollte der Editor direkt deaktiviert werden.

Dazu muss man lediglich folgende Zeile in seine wp-config.php eintragen:

define( 'DISALLOW_FILE_EDIT', true );

Automatische Minor-Updates

WordPress verfügt über eine sehr einfache automatische Update-Funktion. Diese Funktion kann man auch dazu nutzen, dass sicherheitsrelevante Updates, beispielsweise von v4.8.0 auf v4.8.1, automatisch vorgenommen werden, ohne dass man als Administrator/in noch aktiv werden muss.

Dazu muss man lediglich folgende Zeile in seine wp-config.php eintragen:

define( 'WP_AUTO_UPDATE_CORE', minor );

Automatische Installation von Zusatzinhalten deaktivieren

Wenn WordPress installiert wird, werden automatisch die beiden Plugins „Akismet“ und „Hello Dolly“ sowie die Themes „Twenty Fifteen“, „Twenty Sixteen“ und „Twenty Seventeen“ installiert, egal ob man sie benötigt oder nicht. Um bei zukünftigen Updates des WordPress Core nicht auch automatisch eventuell neu hinzugekommene Themes zu installieren, kann man diese Funktion deaktivieren.

Dazu muss man lediglich folgende Zeile in seine wp-config.php eintragen:

define( 'CORE_UPGRADE_SKIP_NEW_BUNDLED', true );

HTTPS erzwingen

In der heutigen Zeit ist die verschlüsselte Übertragung zwischen dem eigenen Browser und dem Server unabdinglich. Dank des Dienstes Let’s Encrypt ist es sehr einfach – und vor allem kostenlos – möglich, sich ein SSL-Zertifikat zu besorgen, um HTTPS zu nutzen.

Achtung! Die nachfolgende Konfiguration darf nur dann genutzt werden, wenn HTTPS bereits erfolgreich auf der eigenen Website funktioniert.

Um sämtliche Aufrufe der Seite über HTTP auf HTTPS umzustellen, muss man serverseitig Einstellungen vornehmen. WordPress bietet jedoch von Haus aus die Möglichkeit, zumindest für die Login-Seite und das Backend HTTPS zu erzwingen.

Dazu muss man lediglich folgende Zeilen in seine wp-config.php eintragen (Zeile 1 für HTTPS auf der Login-Seite, Zeile 2 für HTTPS im Backend):

define( 'FORCE_SSL_LOGIN', true );
define( 'FORCE_SSL_ADMIN', true );

Standardmäßig installierte Plugins entfernen

Wie bereits weiter oben erwähnt, werden die beiden Plugins „Akismet“ und „Hello Dolly“ bei der Installation von WordPress ebenfalls installiert. Während „Akismet“ grundsätzlich eigentlich ein sehr hilfreiches Plugin ist, welches zur Spam-Bekämpfung erstellte Kommentare und ähnliches automatisch analysiert und gegebenenfalls dann nicht aktiviert, ist „Hello Dolly“ lediglich ein Beispiel-Plugin für Entwickler, um sich anzusehen, wie ein simples Plugin aufgebaut ist.

Letzteres hat schon aus dem Grund, dass es nur für Entwickler gedacht ist, nichts auf einer produktiv genutzten Website zu suchen. „Akismet“ verstößt leider dadurch, dass ungefragt Daten an Server, welche in den USA stehen, versendet werden, gegen geltendes deutsches Datenschutzrecht. Daher sollte man beide Plugins deinstallieren.

Warum deinstallieren und nicht einfach deaktivieren?

Nun, deaktivieren sollte man Plugins und Themes nur kurzzeitig, um beispielsweise bestimmte Dinge zu testen. Wird ein Plugin oder Theme aber überhaupt nicht benötigt, wie in dem oben genannten Fall, sollte man es entfernen, um die mögliche Angriffsfläche zu verkleinern (weniger vorhandener Code wird automatisch zu einem kleineren Bereich, der angegriffen werden kann).

Standardmäßig installierte und nicht benötigte Themes entfernen

Ebenfalls oben genannt habe ich die Themes „Twenty Fifteen“, „Twenty Sixteen“ und „Twenty Seventeen“, die automatisch mit WordPress installiert werden. Aus denselben Gründen wie bei den standardmäßig installierten Plugins empfehle ich auch hier, die Themes zu entfernen, die man nicht nutzt. Idealerweise hat man in seiner WordPress-Installation immer nur ein Theme – oder zwei, sofern man mit einem Child-Theme arbeitet.

Fazit

Damit haben wir nun schon grundlegend die Sicherheit der Website ein gutes Stück vorangebracht. Da wir uns jedoch laufend um die Sicherheit unserer Website kümmern müssen, kommt im nächsten Teil der Reihe „WordPress-Sicherheit“, was man tun muss, um seine WordPress-Installation kontinuierlich sicher zu halten. 🔐

3 thoughts on “WordPress-Sicherheit #2 – Erste Konfiguration

  1. […] Die Installation und erste Konfiguration haben wir hinter uns gelassen. Nun geht es darum, sicherzustellen, dass unser WordPress abgesichert bleibt. Vieles kann man serverseitig bereits machen, hier sind die Hoster in der Pflicht, sofern man selbst nur Webspace mietet. Allerdings kommt man nicht umhin, die Sache selbst proaktiv anzugehen. […]

  2. Der Abschnitt mit den Benutzernamen ist ein wenig zu kurz geraten und enthält ein paar Fehler. Rainbow Tables gibt es nicht für Benutzernamen (vielleicht meinst du hier die typischen Ersetzungen adm1in, r00t, etc. – das hat aber nichts mit Rainbow Tables zu tun). Rainbow Tables sind eine Möglichkeit schnell zu einem Passwort den Hash-Wert zu finden. Was einem nicht hilft, wenn man bei der Installation die Sicherheitsschlüssel (Salt) genutzt hat. Dann ist die Zuordnung Hash zu Passwort nicht mehr einfach möglich.
    Siehe: https://de.wikipedia.org/wiki/Rainbow_Table
    Da der Benutzername an vielen anderen Stellen verraten wird, ist dieser Tipp aber sowieso eher „Snake Oil“:
    http://torstenlandsiedel.de/2016/02/28/sicherheitsmythos-anmeldenamen-in-wordpress-verstecken/
    Die ganzen einfachen Bot-Angriffe gehen so ins Leere, aber das tun sie bei einem anständigen Passwort sowieso. Mehr Sicherheit hat man trotzdem nicht. Denn wer dich wirklich angreifen will, der kommt an deinen Benutzernamen auch so ran (z.B. über die REST API).
    Automatische Minor-Updates sind übrigens standardmäßig so schon konfiguriert. Siehe Codex:

    For development sites, the default value of WP_AUTO_UPDATE_CORE is true. For other sites sites, the default value of WP_AUTO_UPDATE_CORE is minor.

    Idealerweise hat man in seiner WordPress-Installation immer nur ein Theme – oder zwei, sofern man mit einem Child-Theme arbeitet.

    Für das Debugging kann es durchaus Sinn machen zumindest eines der Standardthemes zu behalten. Zum Beispiel das jeweils aktuellste. Das wird aktiv entwickelt und sollte das Theme Probleme machen, so springt WP auf ein Standardtheme zurück (sofern vorhanden).

    1. Den Absatz werde ich auf jeden Fall dann nochmal überarbeiten, danke für das Feedback!
      Mir ist klar, dass WP_AUTO_UPDATE_CORE standardmäßig bereits auf true steht, allerdings empfinde ich es als sinnvoll, das selbst aktiv zu setzen. Wer weiß, wie der Standardwert in Zukunft irgendwann eventuell einmal sein wird…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.