Ein Thema, welches ich im Buch leider vernachlässigt habe, ist das Thema Sicherheit. Dieses Thema ist aber immer relevanter, gerade weil WordPress immer populärer wird und damit auch immer interessanter für Hacker und Andere, die sich unbefugt Zutritt zu einer Web-Applikationen geben wollen.

Nicht zuletzt ist der Artikel also eine Aufforderung vieler Leser, die mir per E-Mail oder Online-Rezension, einen Hinweis darauf hinterlassen habe und denen ich mit diesem Artikel ein wenig helfen möchte, ihre WordPress-Installation sicherer zu machen.

Kurz & Knapp - so werde ich also im folgenden einige Tipps für ein sicheres Weblog mit WordPress geben.

Sicherheit - einen Zustand, der frei von unvertretbaren Risiken der Beeinträchtigung ist oder als gefahrenfrei angesehen wird.

Wikipedia

Aber Achtung, damit will und kann ich nicht die Eigenverantwortung des jeweiligen Administrators herabsetzen oder abnehmen. Das Thema wird immer wieder präsent sein und die Sicherheitsregeln werden sich ändern. Nichtsdestotrotz kann man mit einigen wenigen Schritten die Installation recht sicher gestallten.

1. User-Name

   Nach jeder Installation ist der Standard-User-Name des Administrators admin. Diese Login-Name gehört als erstes geändert. Dieser Login-Name ist bekannt und sorgt dafür, dass eine unberechtigte Person nur noch an einem Wort tüfteln muss - dem Zugangspasswort. Mit einem eigenen Login-Namen erhöht man die Sicherheit des Systems.

   Ist der Blog schon eine weile im Betrieb, so hat das Login sicher einiges an Daten - Artikel, Kommentare. Aber keine Angst, WordPress erlaub beim Löschen eines Users die Übernahme aller Daten auf einen anderen User.

   1.1. User ID

   Wer sich nicht vor dem Zugriff und dem Ändern in der Datenbank scheut, dem sei das Ändern der ID zu empfehlen. Die Standard-IDs 1 und 2 werden am ehesten von Hackern genutzt.
   Achtung, dazu muss die user_id in den Tabellen _users und _usermeta gleich sein! Ebenso gilt es die Tabelle _posts, _links mit dem neuen ID zu versehen, Spalte post_author.
   UPDATE `wp_users` SET `ID` = “815″ WHERE `wp_users`.`ID` = 1;
UPDATE `wp_usermeta` SET `user_id` = '815' WHERE `wp_usermeta`.`user_id` = 1;
UPDATE `wp_posts` SET `post_author` = '815' WHERE `wp_posts`.`post_author` = 1;
UPDATE `wp_links` SET `link_owner` = '815' WHERE `wp_links`.`link_owner` = 1;

   Tipp

   Ich habe das Plugin Search & Replace erweitert und nun kann man mit einem Klick die User-Id und das User-Login einfach ändern, Kenntnisse im Bereich SQL sind nicht erforderlich.

2. Tabellen-Präfix

   Der Tabellen-Präfix von WordPress ist im Standard wp_. Dieser ist in der wp-config.php hinterlegt.

   Neuinstallation

   Bevor WordPress installiert wird, sollte dieser Präfix geändert werden, in einen beliebigen Präfix, der nicht einfach auch das System schließen lässt.
   In der Regel hat WordPress bei vielen Anwendern sicher eine eigene Datenbank und so muss der Präfix nicht auf das System schließen lassen.

   
   // Wenn du verschiedene Präfixe benutzt kannst du innerhalb einer Datenbank
   // verschiedene WordPress Installationen betreiben
   $table_prefix  = 'wp_';   // Nur Zahlen, Buchstaben und Unterstriche bitte!
   

   $table_prefix = '08xyz15_'; // Nur Zahlen, Buchstaben und Unterstriche bitte!

   Bestehende Installation

   Was nun aber, wenn das Blog schon aufgesetzt und in Betrieb ist. Auch dann empfiehlt sich die Änderung des Präfix in eine kryptische Variante.

   Natürlich muss auch dazu der Präfix in der wp-config.php geändert werden. Nun weis WordPress zwar, wie der neue Präfix lautet, aber die bestehenden Tabellen in der Datenbank haben diesen neuen Präfix noch nicht und das Blog kann somit nicht funktionieren.

   Mit Hilfe eines SQL-Kommandos ist aber auch dies recht schnell zu beheben. Dazu nutzt man am besten phpMyAdmin, welches bei vielen Webhostern vorinstalliert ist.
   Die folgende SQL-Anweisung benennt die Tabelle links um.
   RENAME TABLE wp_links to 08xyz15_links;

   Diese Anweisung führt man für jede bestehende Tabelle aus. Dabei hat WordPress, ab Version 2.3, im Standard 10 Tabellen: comments, links, options, postmeta, posts, terms, term_relationships, term_taxonomy, usermeta, users.

   
   RENAME TABLE wp_comments to 08xyz15_comments;
   RENAME TABLE wp_links to 08xyz15_links;
   RENAME TABLE wp_options to 08xyz15_options;
   RENAME TABLE wp_postmeta to 08xyz15_postmeta;
   RENAME TABLE wp_posts to 08xyz15_posts;
   RENAME TABLE wp_terms to 08xyz15_terms;
   RENAME TABLE wp_term_relationships to 08xyz15_term_relationships;
   RENAME TABLE wp_term_taxonomy to 08xyz15_term_taxonomy;
   RENAME TABLE wp_usermeta to 08xyz15_usermeta;
   RENAME TABLE wp_users to 08xyz15_users;
   

   Im Anschluss ist man nicht fertig! In den Tabellen options und usermeta müssen noch 4 Felder geändert werden. Dazu kann man folgenden Ql-Syntax nutzen.
   UPDATE 08xyz15_options SET option_name = REPLACE(option_name, 'wp_', '08xyz15_');
UPDATE 08xyz15_usermeta SET meta_key = REPLACE(meta_key, 'wp_', '08xyz15_');

   Sollte es aus irgendwelchen Gründen, z.B. ein Plugin, noch weitere Felder mit dem alten Präfix geben, dann kann man diese mit der folgenden Anweisung finden.
   SELECT * FROM 08xyz15_options WHERE option_name LIKE 'wp_%';
SELECT * FROM 08xyz15_usermeta WHERE meta_key LIKE 'wp_%';

   Handelt es sich um eine Installation kleiner WordPress Version 2.3, dann müssen folgenden 10 Tabellen berücksichtigt werden: categories, comments, link2cat, links, options, post2cat, postmeta, posts, usermeta, users.

   Natürlich gibt es auch für diese Arbeit ein Plugin, welches einem Anwender die Arbeit erleichtert und die Ändern schnell durchführt: WP Prefix Table Changer.

3. Plugin Verzeichnis schützen

   Das WordPress-Entwickler-Team empfiehlt die Sicherung durch einen einfachen Schutz, kopiere eine leere index.html in das Plugin-Verzeichnis /wp-content/plugins/. Damit ist man auf der sicheren Seite, falls der Apache das Anzeigen von leeren Verzeichnissen zulässt.

4. WordPress Version verschleiern

   WordPress hinterlegt in den Core-Daten die Version der Installation und der Datenbank. Bisher hat man in der Regel im Theme die Version eingepflegt. Diese dient lediglich statistischen Erhebungen, denn darüber konnte man ein wenig die jeweils aktuell verfügbaren Installationen recht einfach erkennen.

   Die Entwickler von WordPress empfehlen seit geraumer Zeit, dass man diesen Tag aus dem Theme entfernt um die Identifizierung zu erschweren. Dazu ist im Theme in der Regel die header.php zu ändern, in einigen Themes auch die index.php.

   <meta name="generator"
   content="WordPress <?php bloginfo('version'); ?>" />

   Die obige Zeile also entfernen.

   Allerdings sollte man nicht verschweigen, dass man trotzdem die Version von WordPress in der einen oder anderen Funktion benötigt und das man die Version beispielsweise im Feed auslesen kann. Einige Plugins beispielsweise greifen auf die Version zu und können so auf unterschiedliche Installationen reagieren. Die Version der WordPress-Installation und der Datenbank ist immer in /wp-includes/version.php zu finden. Wer also die Version komplett verschleiern will, der ändert den Eintrag in dieser Datei. Sollte es dann aber zu Problemen mit dem einen oder anderen Plugin oder Theme kommen, dann sollte man sich zumindest an diesen Eingriff erinnern.

   $wp_version = '2.2.3';
   
   $wp_db_version = 5183;
   

   Ebenso ist darauf zu achten, nach jedem Update der Installation ist diese Datei wieder hergestellt.

   Mit dem Löschen bzw. Ändern des Eintrags funktioniert außerdem der automatische Hinweis auf eine neue Version und der Hinweis auf neue Plugin-Versionen, der seit WordPress Version 2.3.1 vorhanden ist, nicht mehr zuverlässig bzw. gar nicht.

   Tipp

   Ich habe ein Plugin erstellt, was die Version von WordPress ersetzt, entweder mit einer Zufallszahl oder ab Version 2.4 wird der komplette Tag gelöscht. Damit werden keine Informationen nach außen getragen und man muss nach einem WP-Update nicht die Core-Dateien ändern.
   Weitere Information und Download des Plugins sind auf meinem Privaten Blog im Artikel WordPress Version verschleiern (Plugin) zu finden.

5. WordPress User-Logins reduzieren

   Im Normalfall hat das Backend nur so viele User, wie man auch wirklich Personen hat, die im System arbeiten. Test-User oder Überbleibsel gehören gelöscht.
   Ein Augenmerk gehört den Rechten. Es ist zu überprüfen, welche Rechte jeder User hat und ob diese wirklich notwendig sind. Es ist kein Zeichen von Angst oder Geiz, wenn die Rechte der User eingeschränkt sind, auf die jeweiligen Anforderungen und Bedürfnisse zugeschnitten.

   Ein Tipp

   Mit Hilfe des Plugins Role Manager Members lassen sich hervorragend Benutzerrechte erstellen. So lassen sich einfach und übersichtlich entsprechend zugeschnittene Rollen für die jeweiligen Nutzer-Aufgaben erstellen, falls die Rollen im Standard nicht ausreichen.

6. WordPress aktualisieren

   WordPress Core

   Nicht zu letzt ist es wichtig, dass die Installation immer auf dem aktuellen Sicherheitsstand ist, das heißt: Spiele immer das aktuelle Release ein! Die aktuelle Release-Version sichert die Sicherheit von WordPress.
   Das heißt nicht, dass man immer die aktuellste Version von WordPress installiert haben muss. Aber das aktuellste Release der verwendeten Version sollte eingespielt sein.

   Um auf dem aktuellen Stand zu bleiben, bietet es sich an, den Feed von WordPress zu abonnieren bzw. immer mal den Tellerrand des eigenen Blogs zu lesen, denn dort wird der Feed-Inhalt dargestellt.
   Ab der Version WP 2.3.1 weist das System darauf hin, dass es eine neue Revision/ Version gibt. Wer den Zugriff nicht ermöglich will, der findet eine Reihe von Plugins im offiziellen Plugin-Verzeichnis, die diese Verbindung unterbrechen.

   WordPress Plugins

   Gleiches gilt für Plugins. Plugins stellen neue Funktionalitäten innerhalb des Systems und können damit neue Sicherheitslücken einbringen. Vertraue nicht jedem Plugin und versuche die Plugins immer auf dem aktuellen Stand zu halten, auch wenn meist neue Versionen neue Funktionalitäten einbringen.

   Im weiteren gehören nicht genutzte Plugins nicht in das laufende System. Werden sie nicht benötigt, dann gehören sie entfernt.

   WordPress Theme

   Auch Themes können Sicherheitsprobleme aufweisen! Themes mit ihren Templates nutzen PHP-Funktionen und können neue Funktionen im Bauch haben. Damit können Sicherheitslücken auftauchen. Es gilt also ebenfalls, auch Updates des Autors achten.

7. WP Plugins minimieren

   Wie schon im vorherigen Punkt erwähnt, Plugins können neue Sicherheitslücken in das System einbringen. Daher sollte immer die Überlegung gelten, muss es wirklich dieses Plugin sein. Bringt es Mehrwert und eventuell sollte man prüfen, wie gut ist das Plugin. Natürlich ist es schwer, vor allem wenn man keine PHP-Kenntnisse hat, den Code zu inspizieren und damit ein eventuell bestehendes Problem zu finden. Aber trotzdem kann man ein wenig die Seriosität des Plugin-Autors prüfen. Hat der Autor eine Anleitung zum Plugin, gibt es negative Schlagzeilen bzw. Blogeinträge und Kommentare und ist das Impressum des Autors gepflegt? Kleinigkeiten, die aber einiges über den Autor und das Plugin aussagen können.

   1. Die Grundregel lautet jedoch: Verwende so wenig wie nötig Plugins.
   2. Un die zweite Regel: Teste Plugins nicht im Live-System, ein Vorabtest in einer lokalen Installation kann viele Probleme verhindern.

Auch der zweite Punkt hat wichtige Relevanz. Immer wieder holen sich User Problem und unnötige Daten in ihr System. Viele Plugins benötigen Einstellungen, die in der Tabelle options abgelegt werden. Diese Daten bleiben bei den meisten Plugins auch nach dem deaktivieren des Plugins in der Tabelle bestehen!

8. Eingeschränkter Login auf wp-admin

   Ist der Zugriff auf das Backend nur von einem oder wenigen Rechnern gesichert, so kann man den Zugriff einschränken und damit die Sicherheit weiter steigern. Der Zugriff ist einfach per .htaccess zu beschränken. Information zu .htaccess gibt es viele im Internet. Die Zugriffssperre könnte zum Beispiel für zwei IPs wie folgt aussehen.

   AuthUserFile /dev/null
   AuthGroupFile /dev/null
   AuthName "Access Control"
   AuthType Basic
   Order deny,allow
   Deny from all
   # Whitelist IP Adresse
   Allow from 255.08.15.1
   Allow from 255.08.15.2
   

   Diese Syntax in eine leere Datei ablegen und die eigenen IPs hinterlegen und die Datei als .htaccess speichern. Die Datei im Anschluss im Ordner /wp-admin/ ablegen.

   Ob man den Zugriff einschränken muss und will, das muss jeder Anwender selbst entscheiden.

   Aber es damit ist natürlich die schöne Funktionalität einer Web-Applikation dahin, von überall auf das System zugreifen zu können.

   via Plugin

   Alternativ kann man dies auch per Plugin realisieren, was einfacher und schneller für den Laien zu bewerkstelligen ist. Als Plugin dient das Login Lockdown Plugin oder AskApache Password Protect.

9. Eingeschränkter Zugriff auf wp-content und wp-includes

   Mit Hilfe einer .htaccess kann man ein ganze Reihe von Daten schützen. Mit Hilfe dieser Methode empfiehlt es sich den Zugriff nur auf bestimmte Datei-Formate, wie Bilder, Stylesheets und JavaScript zu beschränken.

   Order deny,allow
   Deny from all
   <Files ~ ".(xml|css|jpe?g|png|gif|js)$">
   Allow from all
   </Files>

   Der obige Syntax wird wieder in einer .htaccess gespeichert und die Ordner /wp-content/ und /wp-includes/ kopiert. Die Datei-Endungen im Syntax müssen natürlich angepasst werden, je nach dem, auf was für Dateien man zugreifen muss.

   Aufpassen, das eine oder andere Plugin benötigt den Zugriff auf php-Dateien. Daher den Syntax in dem Fall um php erweitern. Zumindest für die .htacces in /wp-content/ empfiehlt sich die Aufnahme von php. Ähnlich verhält es sich, wenn man den Cache von WordPress aktiv hat, dann muss man den Zugriff auf lock erlauben.

   # Allow only css,jpe*g,png,gif,js
   Order deny,allow
   Deny from all
   <Files ~ ".(php|lock|xml|css|jpe?g|png|gif|js)$">
   Allow from all
   </Files>
   

   Im weiteren ist darauf zu achten, dass man nur eine .htaccess-Datei im Ordner hat. Sollte man also ebenfalls den Zugriff per .htaccess aus Punkt 8 nutzen, so muss der Syntax in einer Datei untergebracht werden.

10. Schütze die wp-config.php

    Ein weiterer Schutz ist der Zugriff auf die wp-config.php, in der alle Daten zum einloggen in die Datenbank hinterlegt sind. Im Grunde gibt es diesen Zugriff nicht, aber mit dieser kleinen Erweiterung in der .htaccess im root-Verzeichnis der Installation, geht man auf Nummer sicher.

    # protect wp-config.php
    <files wp-config.php>
    Order deny,allow
    Deny from all
    </files>
    

    Viele weitere Informationen dazu mit einigen Beispielen und Diskussionen findet man im zugehörigen Artikel auf meinem privaten Blog.

11. Sicherheit prüfen

    Das Team von BlogSecurity bietet die Online-Version des WP-Scanners schon eine geraume Zeit an und aktualisiert diesen auch immer wieder.

    Nicht immer liegt es an den Dateien von WordPress, auch das Theme kann Sicherheitslücken enthalten.

    Um das eigene Blog zu scannen, muss lediglich ein Kommentar in der header.php bzw. index.php, falls es keine header.php gibt, hinterlegt werden.
    <!-- wpscanner -->

    Der Scan ist kritisch zu sehen aber er hilft und erleichtert die Arbeit.