WordPress Security

Während des Betriebs von WordPress kommt es sehr schnell zur Frage: wie absichern? 

Bei mir kam die erste Angriffswelle nach den ersten Publikationen über mein Blog auf anderen Foren. Zuerst habe ich mich über den rasant ansteigenden Traffic gefreut!. Aber schnell war klar, das ist kein vermehrtes freundliches Interesse sondern Angriffsversuche! Also war die Zeit gekommen aktiv zu werden, so gut es eben geht. 

Es ist mir wohl,recht gut gelungen, denn nach wenigen weiteren Maßnahmen war der Spuk schon wieder vorbei.

Wer also erst gar nicht in so eine Situation kommen will, sollte vorher schon aktiv werden. Was es  alles grundlegendes  zu beachten gibt habe ich  hier zusammengefasst.

Checkliste

Zur generellen Überprüfung anbei eine kleine Checkliste.

Nutzerkennung und Passwort

• Keine Verewendung von bekannten Namen für admin, test, root, Datenbankzugriff, etc.
• Starke, sichere Passwörter im Einsatz. Speicherung in einem Passwort Manager
• Datenbank hat ungewöhnlichen Tabellen Präfix (nicht “wp_”, sondern bspw. “sduz2_”)
• Datenkank Nutzer hat nur Zugriff auf die WordPress Datenbank

WordPress Zugriff

• wp-config.php Zugriff abgesichert ( .htaccess)
• xml-rpc.php Zugriff limitiert oder deaktiviert (.htaccess)
• Zugriffsrechte auf Dateiebene minimiert (nur http Server und Nutzer der Site)

WordPress Config

• SSL In Verwendung für Admin UND Nutzer Logins
• Theme Editor Missbrauch Schutz (DISALLOW-FILE_EDIT)

Absicherungsthemen

SPAM

Zugegeben, im Moment musste ich noch nie mit Spam kämpfen, aber das kommt bestimmt noch. Es kann aber auch sein, dass bereits mein Grundschutz mit Wordfence und Aksimet ausreichend ist.

 Was mich noch stören könnte sind zu viele Spam Kommentare von Robots. Sobald ich diese erhalte werde ich zwei weitere Maßnahmen durchführen:

• alternative Kommentarlösung verwenden, bspw. Disqus
• Captcha für Jetpack aktivieren
• oder ganz auf Kommentare verzichten

Login Attacken

Die meisten Attacken versuchen ganz offensichtlich Standardlücken auszunutzen. Dabei hat es sich schon in der Vergangenhheit gezeigt, das als Gegenmaßnahme Verschleierung  praktisch nie hilft, sondern höchstens Angriffe verzögert, diese schlechter erkennbar macht  und die eigene Bedienung unnötig kompliziert. Richtige Härtung dagegen und die Abwehr unberechtigter Anmeldungen funktioniert äußerst effektiv. 

Man kann also getrost auf die “Sicherheitsoptionen” mancher Anbieter , wie die Login URL umbenennen, Logins blockieren etc. verzichten, wenn man ein paar grundlegende Maßnahmen am Webserver selbst vornimmt.

Natürlich sollte man es auch vermeiden für seine wichtigen Nutzer, die Administratoren bspw.oder den Datenbankanwender einfache Namen und Kennwörter zu verwenden. Meine Empfehlung: zufällig erzeugter Nutzername und ein komplexes Passwort. Da man sich das selber garantiert nicht mehr merken kannn ist auch die Verwendung eines Passwort Managers obligatorisch. Ich selbst verwende gerne 1Password, welcher aufgrund seiner tollen Integration in Betriebssysteme und Browser empfohlen werden kann. Aber es gibt genügend andere Alternativen.

Plugins

Wir reden hier um ein privat betriebenes Blog. Kommerziellen Nutzern würde ich professionelle Unetrstützung durch bspw. einen Consultant mit Referenzen und ein Audit der eigenen Seite empfehlen. Das Vertrauen in remote Services und Tools wird niemals die individuelle Installation einer Seite durchleuchten können. Auch Provider leisten sehr unterschiedliche Arbeit, was die Bereitstellung der Server betrifft.

Für die private Nutzung allerdings kann man durchaus zu einer Auswahl gängiger Plugins raten. Meine kleine Zusammenfassung findet sich bei der Auswahl der Basis Plugins.

Maßnahmen im Einzelnen

wp-config.php

Toller Artikel zur Absicherung dieser wichtigen Datei findet sich bei OSTraining. Unbedingt zu empfehlen (auf Englisch)!

Hier die Kurzzusammenfassung der Empfehlungen:

• Nur SSL Verbindungen für den Admin Bereich zulassen
• Nur SSL Verbindungen zulassen für die Anmeldung
• Ein Salt setzen für jeden KEY. Mittels https://api.wordpress.org/secret-key/1.1/salt/
• Verhindern dass man den Themen-Editor missbraucht (DISALLOW_FILE_EDIT)

Daneben gibt es noch weitere Hinweise, die jeweils individuell umzusetzen sind:

• die wp_config.php Datei in ein anderes Verzeichnis zu verschieben
• die wp_config.php Datei mit .htaccess gesondert abzusichern
• Zugriffsrechte sollten minimal sein (nur für den owner der Site).
• die Datenbanktabellen sollten nicht mit wp_ beginnen (nachträglich ändern geht auch mit phpMyAdmin, dauert halt etwas)
• der Datenbanknutzer sollte ein zufälliger Name sein mit starkem Passwort

Auch die Geschwindigkeit sollte man nicht vernachlässigen, denn so gewinnt man etwas Zeit bei Denial of Service (DoS) Attacken. Grundeinstellungen hier wären:

• die Anzahl der Revisionen gering halten
• genug Speicher für WordPress zur Verfügung stellen

Meine Ergänzungen zur wp_config.php sehen dann wie folgt aus:

/* Admin security */
define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true);

define('DISALLOW_FILE_EDIT', TRUE);

define('AUTH_KEY', '/aK/0P@C|]+jl;zP:Y1Cw~udN$eNC1i/A@xT~f0qZ,9+#>S*C9LA`Dua+d8<,d`w');
define('SECURE_AUTH_KEY', 'wUV0u(wrFamp;TK%BX*=j4KG25|Qc-v8U2BlfU!OYko|,F0Rz`;7eB>whxYY=,;l,~'); 
define('LOGGED_IN_KEY', 'cAd,+_ed>:wdaTswMT&`B|`$hCyiAq7`pFZlN [g2*2n<6i&1ZwCymi(80ygb9y-'); 
define('NONCE_KEY', '.J%?Y1j[S?P,T(tml_)8DT~3<P1A-o4<8l[59av]%G>U <q>B/N _+[Fw&!m&{@6'); 
define('AUTH_SALT', '0] K-RL=B?.@Y,}}o`jC+@|,HX Cz1Q=FLJ5kSY+/rL~|I`TzwdM;=eY|fjjJbUz'); 
define('SECURE_AUTH_SALT', '|G$;!I<s-mLQ<m(&E3]iC@LAz3rj<Jd4zwi8L(&YrS]I`|ay7lMiFJ*%,DNKIj86');
define('LOGGED_IN_SALT', 'hqi{S~Q-KvKQ0?`=h0Te]J|9T9e(.8nuWq70N-$1;0<K[3<-*hpQ<|K#6tf<OtLs'); 
define('NONCE_SALT', 'h_{Skrp?X-w%2Pg pfv-ISZ5s:tBz#o9)[>EjP0K2SbPMZ#lB!vCCMuhTo)X)9G('); 

/* Optimize revisions */ 
define('WP_POST_REVISIONS', 5);

/* more memory, we've got a lot … */
define('WP_MEMORY_LIMIT', '128M');

Nutzernamen & Passwort

Den ersten Effekt den ich bei Login-Attacken gesehen habe war, dass die üblichen Accountnamen wie “admin” oder “test” verwendet wurden.

Aber auch etwas anderes: die registrierten Nicknamen auf WordPress.org oder WordPress.com sowie die Authorennamen werden getestet!

Daher sollte man folgendes tun:

• der Anzeigenamen sollte NIE mit dem registrierten Kurznamen übereinstimmen
• der registrierte Kurznamen für den Administrator und andere Nutzer mit hohen Rechten sollte zufällig sein.

Leider kann man Kurznamen nachträglich nicht mehr ändern. Daher sollte man sich vorab diesen gut überlegen! Man kann aber nachträglich Artikel einem neuen Nutzer zuweisen. Das geht folgendermaßen:

1. neuen Benutzer anlegen
2. alten Benutzer löschen. Im Dialog kann man nun alle Artikel dem neuen Benutzer zuweisen lassen
3. sollte der Benutzer genutzt worden sein um mit JetPack zu connecten
4. auf WordPress.COM anmelden und JetPack Verbindung trennen
5. Sicherheitshalber auch auf der eigen Site die Verbindung überprüfen und gegebenenfalls trennen
6. etwas warten (sonst erhält man connect transport error - HTTP status code was not 200 (502) Fehlermeldung)
7. neu verbinden

Zugriff auf Login und Admin Bereich schützen

Der folgende Tipp ist wahrscheinlich einer der wichtigsten! Er hat sofort Wirkung gezeigt und die Anzahl der Hack-Versuche wieder minimiert.

Auf meinem Blog bloggt nur einer: ich. Daher kann ich sowohl den Admin Bereich als auch den Login Bereich durch einen serverseitigen Schutz bereits absichern. So kommt es erst gar nicht zu login Versuchen auf der WordPress Seite.

Auf meinem Server (Diskstation mit DSM 6.x) läuft zwar nginx, aber als Frontend benötige ich noch Apache, aus Kompatibilitätsgründen mit den Permalinks (hoffentlich wird das durch Synology bald behoben!). Also verwende ich eine .htaccess Datei wie bei Kuketz beschrieben um den Zugriff einzuschränken

• .htpasswd anlegen mittels htpasswd Generator
• .htaccess ergänzen

# 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>

Eines noch: es stellt sich natürlich die Frage, warum das nicht gleich vor dem Angriff bei mir schon eingestellt war. Ich muss zugeben es gab nur einen Grund: Faulheit. Gerade am Anfang will man schnell vorankommen und schiebt dann einiges auf später. Meine Empfehlung daher: nicht gut. was du heute kannst besorgen, verschiebe nicht auf morgen. Nirgends ist dieser Spruch wohl so wichtig wie beim Thema Sicherheit.

Login URL ändern

Will man wieder etwas mehr Komfort, bei gleichzeitig verbesserten Schutz, kann man die Login URL auch ändern. Aus wp-login von https://meineseite.de/wp-login wird dann etwa meineseite.de/asdfiuz. Das sollte nun schwerer zu erraten sein, und verhindern dass automatisierte Bots auf die Login-Seite einprügeln.

Das Folgende ist aber nicht wirklich einen Sicherheitsmassnahme, da es dem Motto folgt “Security through obscurity” also Verschleierung. Ein Angreifer kann im Ernstfall immer noch die echte Login-URL herausbekommen.

Um die URL zu verstecken gibt es einige Plugins. Ein einfache, effiziente Variante ist WPS Hide Login

Tipp: man kann das auch wunderbar kombinieren. Durch die Methode mittels eines Passwords direkt mit dem Webserver die wp-login.php abzusichern, werden Bots schon einen Schritt vor der Haustüre abgewimmelt und kommen erst gar nicht dazu den Klingelknopf zu drücken. Würde man nur diese Verschleierungsmethode nutzen, könnten Bots auch weiterhin versuchen auf die wp-login.php zuzugreifen, was dann zwar durch WordPress abgeblockt wird, aber erstmal Last produziert. Denial of Service Attacken wären so einfacher. Also wenn Login URL ändern, dann nicht auf die dumme Idee kommen jetzt nicht mehr die wp-login.php absichern zu müssen, weil man “nutzt die ja eh nicht mehr”.

XML-RPC

Viele Attacken laufen über Brute-Force Passwort Angriffe über die XML-RPC. Dabei darf man nicht vergessen, dass mit einem einzigen API Aufruf mehrere hundert Abfragen gleichzeitig durchgeführt werden können! Klingt unheimlich! Ist es aber nicht und man kann sich gut schützen, und zwar wie folgt.

Methode 1

Während wohl die meisten Security Plugins (bis auf Wordfence) einen Mechanismus eingebaut haben, die xml-rpc.php zu deaktivieren, würde diese Aktion auch jeglichen Zugriff über JetPack oder WordPress Apps unterbinden. Denn dafür ist die xml-rpc.php hauptsächlich da. Mein Weg ist daher ein anderer.

Das Stop XMLRPC Plugin  nutzt  die .htaccess Datei um jeglichen Zugriff auf die xml-rpc.php Datei zu verhindern, mit Ausnahme der Server von Automattic, den Herstellern von JetPack und Betreiber von WordPress.com. Damit bleibt das Hautpfeature erhalten und der Löwenanteil der Angriff bleibt aussen vor. Funktioniert super! In Kombination mit zufälligen Nutzernamen und starken Passwörtern sollte so kaum mehr etwas passieren.

Methode 2

Neuer Versionen von WordPress und das aktuelle JetPack benötigen kein XML-RPC mehr, sondern nutzen die modernere REST-API, welche auf OAuth setzt. Daher kann bei neuen WordPress Installation mittels des Plugins Disable XML RPC die Funktionalität komplett abgeschaltet werden. Pingbacks und Trackbacks wären die einzigen Funktionen die wohl auch heute noch auf die alte Schnittstelle setzen, die Funktionen werden aber kaum noch eingesetzt und kann man für seine Webseite generell auch deaktivieren.

Am Ende kann man den „Erfolg“ der Deaktivierung oder des Schutzes mit folgendem Tool überprüfen: XML-RPC Validation Service

Fazit

Mit den hier aufgeführten Maßnahmen kann man seine WordPress Installation sehr gut absichern. Absoluten Schutz wird es nie geben, aber ein einfaches Angriffsziel ist man auf keinen Fall mehr.

Zusätzlich sollte man natürlich nicht vergessen, seine Server und sein Netzwerk ebenfalls gut zu sicher, aber das ist ein anderes Thema.

Ressourcen

• Directer Plugin Update Directer Plugin Update oder FTP FTP etc. (FS_Method direct)
• Hervorragender Blog von Kuketz zur allgemeine Absicherung. Absolut lesenswert!
• Eine sehr gute Übersicht und Beurteilung zu Security Plugins (Englisch)
• Artikel zur Behandlung von XML-RPC und dessen Ablüsung durch REST APIs in zukünftigen WordPress Versionen.
• Beurteilung der Notwendigkeit von XMLRPC in aktuellen WordPress Versionen von Kinsta
• Login Link verstecken mit WPS Hide Login