WordPress – aber sicher!

WordPress verwendet unterschiedliche Rollen mit unterschiedlichen Berechtigungen, diese sollten auch genutzt werden.

 

Benutzername

Viele Seiten mit WordPress werden von einer Person komplett verwaltet. Da ist es naheliegend und bequem, wenn man alles mit einem Benutzer erledigen kann. Doch Vorsicht, genau dies birgt Risiken! Wer als Administrator seine Beiträge schreibt verrät der ganzen Welt auch den Benutzernamen. Wenn dieser nun auch gleichzeitig der Administrator der Seite ist, stehen die Chancen für einen Angreifer sehr gut sich Zugang mit allen Rechten zu verschaffen. Er muss nur noch das Passwort knacken und schon kann er alles machen, was er will. Verwenden Sie daher mindestens zwei Benutzer! Einen für administrative Aufgaben und einen zum Beiträge schreiben.

Vermeiden Sie Standardbenutzernamen wie „admin“ oder „Administrator“, denn gerade diese werden sehr gerne für die ersten LogIn-Versuche getestet. Verwenden Sie statt dessen zwei beliebige andere Namen wie „Otto“ als Redakteur zum erstellen und freigeben der Beiträge und „Otto-0815“ als Administrator um Ihr WordPress zu verwalten.

 

Benutzer-ID

Jeder Benutzer erhält automatisch eine fortlaufende Identifikationsnummer (User-ID). Vermeiden Sie, dass die User-ID 1 administrative Rechte hat. Nach Ihrer WordPress-Installation existiert ein Benutzer mit administrativen Rechten, der auch die ID 1 hat. Legen Sie daher nach der Installation zwei weitere Benutzer an. Einen der nur Inhalte erstellen und freigeben darf (Redakteur) und einen für administrative Aufgaben (Administrator). Melden Sie sich wieder ab und mit dem neuen Administrator an. Löschen Sie nun den ursprünglichen Administrator. Und schon existiert die User-ID 1 nicht mehr.

 

Passwörter

Verwenden Sie sichere Passwörter, denn die heutigen Rechner sind schnell genug um innerhalb kürzester Zeit viele Passwörter zu testen. Je einfacher ein Passwort gestaltet ist („qwe123“ oder „test1234“) desto schneller werden diese auch geknackt. Verwenden Sie daher mindestens 8 Zeichen (besser mehr) die aus Groß- und Kleinbuchstaben sowie Ziffern und Sonderzeichen bestehen. Dies erschwert das knacken des Passwort deutlich. Verwenden Sie hierzu zum Beispiel den Passwortgenerator von WordPress oder denken Sie sich einen Satz aus und verwenden Sie davon nur den ersten Buchstaben (zum Beispiel: „Am 31 Dezember ist Sylvester in Deutschland.“ = „A31DiSiD.“.

 

Kurzübersicht Benutzernamen:

• Administrator schreibt keine Texte
• individuelle Benutzernamen
• Löschen der User-ID 1
• sichere Passwörter

Das BackEnd von WordPress erreicht man mit /wp-admin oder /wp-login.php. Das wissen auch die Angreifer. Daher erfolgen BackEnd-Angriffe fast immer auf „ihredomain.tld/wp-login.php“. Um diese Angriffe abzuwehren kann man mit Hilfe von PlugIns (z.B. „WPS Hide Login“) diesen Pfad verändern und wehrt somit die ganzen Standardangriffe per se ab. Sie dürfen dann nur nicht vergessen, wie Ihr neuer Pfad zum BackEnd von WordPress lautet, denn sonst kommen Sie selbst nicht mehr (ohne Weiteres) in Ihr BackEnd.

Bei WordPress hat jede Datenbanktabelle das Kürzel „wp_“ vorangestellt. Dies wird von vielen als Sicherheitsrisiko betrachtet, weil es ja bei nahezu allen WordPress-Installationen gleich ist. Ich persönlich betrachte den einheitlichen Tabellen-Präfix jedoch nicht als sicherheitskritisch, weil:

Zum einen erfolgen nur die wenigsten Angriffe direkt auf die Datenbank.
Zum anderen benötigt man ja auch die Verbindungsdaten zur Datenbank.

Die Verbindungsdaten zur Datenbank stehen in der Konfigurationsdatei „wp-config.php“. Man muss es also erst schaffen, diese Datei von außen auszulesen um die Verbindungsdaten wie Datenbankhost, Datenbankname, Datenbankbenutzer und Datenbankpasswort auszulesen. In dieser Datei steht jedoch auch der Tabellen-Präfix. Wer sich also Zugriff auf diese Konfigurationsdatei verschaffen kann, der kann auch den geänderten Tabellen-Präfix auslesen. Daher betrachte ich eine Änderung des Tabellen-Präfix nicht als sinnvoll. Hinzu kommt noch, dass die Verbindungsdaten zur Datenbank alleine nicht ausreichen. Um Zugriff auf die Datenbank zu erhalten, muss ich entweder eine Schadcodedatei im Anwendungsverzeichnis ablegen oder die Datenbank hat fälschlicherweise Zugriffsrechte von außerhalb. Daher sollten hier zum Schutz andere Maßnahmen ergriffen werden, wie eine Aufrufsperre der Konfigurationsdatei von außen, die Möglichkeit Dateien abzuspeichern oder externe Zugriffsrechte auf die Datenbank.

 

Kurzfassung Datenbank:

• Vermeiden Sie externe Zugriffsrechte auf die Datenbank
• Verbieten Sie das Auslesen der Konfigurationsdatei
• Verbieten Sie das Speichern fremder Dateien

Um Ihre Seite aus dem Internet erreichbar zu machen benötigen Sie einen Webserver, den Ihnen Ihr Hoster zur Verfügung stellt. Gängig sind heutzutage Apache und NGINX. Noch immer am weitesten verbreitet ist sicherlich der Apache bei dem Sie bei den meisten Hostern auch die Möglichkeit haben bestimmte Konfigurationen vorzunehmen.

WordPress verwendet bereits von sich aus die Webserver-Konfigurations-Datei „.htaccess“, welche sich direkt in dem Anwendungsverzeichnis von WordPress (z.B. „/html/wordpress“) befindet. Mit wenigen Regeln können Sie hier diverse Dateien vor einem unerwünschten Zugriff sperren und somit zum Beispiel das Auslesen der Datenbankkonfiguration (wp-config.php) verhindern. Aber auch einige weitere Dateien sollten geschützt werden, weil diese Informationen zur Verfügung stellen, die keinen etwas angehen. Lange Zeit konnte man zum Beispiel über „/liesmich.html“ die installierte Version von WordPress auslesen, was Angreifern Ihre Arbeit erleichtert hat, da sie sich leicht auf alte und unsichere Versionen konzentrieren konnten. Zwischenzeitlich beinhaltet diese Datei zwar nicht mehr den Versionshinweis, sollte aber wie noch einige weitere mit folgenden Regeln in der .htaccess geschützt werden:

### .htaccess sperren ###
# ———————–
<Files .htaccess>
order allow,deny
deny from all
</Files>

### xmlrpc.php sperren ###
### ———————-
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

### wp-config.php sperren ###
# —————————
<Files wp-config.php>
order allow,deny
deny from all
</Files>

### license.txt sperren ###
# —————————
<Files license.txt>
order allow,deny
deny from all
</Files>

### liesmich.html sperren ###
# —————————
<Files liesmich.html>
order allow,deny
deny from all
</Files>

### readme.html sperren ###
# —————————
<Files readme.html>
order allow,deny
deny from all
</Files>

### version.php sperren ###
# —————————
<Files wp-includes/version.php>
order allow,deny
deny from all
</Files>

WordPress macht einem die Aktualisierung sehr einfach. Dennoch ist es erschreckend, wie viele alte WordPress-Versionen man im Internet findet. Neue Versionen enthalten nicht nur neue Funktionen, sondern schließen in der Regel auch bekannte Sicherheitslücken. Dies gilt natürlich nicht nur für WordPress selbst, sondern auch für alle installierten (egal ob aktiviert oder nicht) Themes und PlugIns.

Für Unterversionen aktualisiert WordPress sich seit geraumer Zeit schon selbstständig, also zum Beispiel von 4.9.5 auf 4.9.6. Jedoch spätestens bei einer neuen Hauptversion (z.B. von 4.x auf 5.x) ist eine manuelle Aktualisierung erforderlich, da spätestens dann vom Benutzer vorab eine Sicherung erstellt werden sollte.
Themes und PlugIns werden hingegen nicht automatisch aktualisiert und müssen immer manuell auf den aktuellen Stand gebracht werden und das bitte zeitnah.

Sicherheitshalber sollte vor JEDER Aktualisierung eine Sicherung angelegt werden. In der Masse der Fälle führen Aktualisierungen zwar zu keinen Problemen, zumindest nicht, wenn man immer zeitnah aktualisiert, aber es kann auch mal etwas schief gehen. Daher sind Sicherungen vor jeder Aktualisierung wichtig um im Fall der Fälle zumindest den alten Stand wieder herstellen zu können um dann in Ruhe nach der Ursache suchen zu können.

Gerade bei Firmenseiten, auf denen sich nur selten etwas am Inhalt ändert, bekommen es die Seitenbetreiber oftmals nicht mit, wenn neue Versionen anstehen. In manchen Bereichen wird das BackEnd oft monatelang nicht aufgerufen. Daher sollte man regelmäßig einen kurzen Blick in das BackEnd von WordPress werfen um zu prüfen ob Updates anstehen.

 

Empfehlung:

Der automatische Update-Service „WPtomatic“ prüft nicht nur stündlich auf anstehende Aktualisierungen sondern entzieht den Verzeichnissen und Dateien auch die Schreibrechte wodurch eine unerwünschte Datenmanipulation (Schadcode) vermieden wird.

https://www.wptomatic.de

Für die Erkennung und Abwehr von Angriffen gibt es diverse PlugIns (z.B. Wordfence Security). Leider gehen diese Lösungen meistens auch zu Lasten der Performance (Geschwindigkeit), schützen im Gegenzug Ihre Seite aber vor Angriffsversuchen (z.B. durch IP-Sperrung nach entsprechender Anzahl fehlgeschlagener LogIns).

PlugIns bieten sehr einfach viele Funktionen und verleiten daher schnell dazu, dass man sich mal eben ein passendes PlugIn installiert. Nicht nur, dass jedes PlugIn zu lasten der Performance (Geschwindigkeit) geht, sondern jeder zusätzliche Code enthält auch zusätzliche Risiken. Daher sollte man die Anzahl an PlugIns auf ein Minimum reduzieren.

Viele Kleinigkeiten wie einen Redirect (Umleitung von Seiten) kann man mit wenig eigenem Code direkt in die Konfigurationsdatei des Webserver (.htaccess) schreiben. Die freut nicht nur die Suchmaschinen und beschleunigt die Verarbeitung, sondern erspart einem zusätzliche PlugIns. Ein solcher Umleitungscode könnte zum Beispiel wie folgt aussehen:

RewriteEngine On
Redirect 301 /angebote https://www.roundaboutweb.net/portfolio/

Diese Zeile leitet allen Aufrufe von „https://www.roundaboutweb.net/angebote“ um auf „https://www.roundaboutweb.net/portfolio/“

Es reicht nicht aus PlugIns nur zu deaktivieren. Dies ist eine gute Funktion um mal eben zu testen, ob man ein PlugIn überhaupt noch irgendwo verwendet. Aber um den Code zu entfernen ist es erforderlich das PlugIn auch zu löschen. Manche PlugIns hinterlassen selbst nach dem Löschen noch Spuren in den Verzeichnissen oder in der Datenbank. Diese zu entfernen erfordert dann größere Kenntnisse oder Unterstützung durch kostenpflichtige PlugIn-Lösungen.

 

Tipp:

Testen Sie PlugIns vorab in einer Kopie Ihrer Seite, damit Ihr Livesystem sauber bleibt. Installieren Sie im Livesystem nur getestete PlugIns, die Sie auch wirklich benötigen.

Verwenden Sie nur aktuelle Themes und PlugIns, die auch regelmäßig aktualisiert werden.
Erweiterungen, welche schon ein halbes Jahr oder länger nicht aktualisiert wurden sind in der Regel auch sicherheitstechnisch bedenklich und sollten vermieden werden.

 

PlugIn-Empfehlungen:

Welche PlugIns benötigt werden hängt natürlich von der Aufgabe der Seite ab. Ein Onlineshop benötigt andere PlugIns wie eine OnePage oder ein Blog. Folgende PlugIns empfehle ich jedoch grundsätzlich:

• W3Total für Caching
• YOAST SEO zur SEO-Optimierung
• Broken Link Checker zur Prüfung auf veraltete Links
• Borlabs Cookie – Cookie Opt-in für die DS-GVO

Je nach Anforderung an die Seite kommen dann noch weitere PlugIns hinzu. Dennoch sollte man die Anzahl so gering wie möglich halten. 40 PlugIns sind eindeutig viel zu viel.

Wie bereits weiter oben beschrieben sind für typische Angriffe die Veränderung (Manipulation) von Dateien erforderlich oder sogar das Speichern neuer Dateien um Schadcode ausführen zu können. Der hilfreichste Schutz ist es daher die Verzeichnisse von WordPress so zu schützen, dass keine Schreibrechte mehr existieren. Durch einen solchen Schutz können dann natürlich auch keine Updates oder Installationen von neuen Themes oder PlugIns erfolgen. Hier muss also vor einer gewollten Veränderung erst bewusst der Schreibschutz entfernt werden, bevor man neue PlugIns installiert oder aktualisiert. Dies bietet jedoch den höchsten Schutz vor einer unerwünschten Datenmanipulation.

 

Empfehlung:

Der automatische Update-Service „WPtomatic“ prüft nicht nur stündlich auf anstehende Aktualisierungen sondern entzieht den Verzeichnissen und Dateien auch die Schreibrechte wodurch eine unerwünschte Datenmanipulation (Schadcode) vermieden wird.

https://www.wptomatic.de