WordPress: Härtung unter Linux

WordPress gehört zu den am weitesten verbreiteten Webblog-Systemen unter den Content-Management-Systemen und ist bei nahezu jedem Webhoster nutzbar. Dieses Tutorial behandelt die Absicherung von WordPress auf einem Linux-Server mit administrativem Root-Zugang.

Bei der Sicherheitsstrategieerstellung sollten Sie vier Gesichtspunkte ins Auge fassen:

  • Die Deinstallation nicht benötigter Software
  • Die Zugangsbeschränkung
  • Die Schadensbegrenzung
  • Den Notfallplan

Deinstallation nicht benötigter Software:
Viele der populären Plugins und Themes innerhalb von WordPress enthalten schwerwiegende Sicherheitslücken. Allein im Monat April 2013 waren es elf öffentlich bekannte. Die Dunkelziffer dürfte hier weitaus höher liegen.

  • WordPress Facebook Members – 5.0.4
  • XSS WordPress FourSquare Checkins Plugin – 1.2
  • XSS WordPress Formidable Pro – 1.06.08
  • XSS All in One Webmaster plugin – 8.2.3
  • XSS WordPress Background Music Plugin “jPlayer” – 1.0
  • XSS Haiku minimalist audio player – 1.0
  • XSS Jammer plugin – 0.2
  • XSS SyntaxHighlighter Evolved – 3.1.6
  • XSS Top 10 plugin – 1.9.2
  • XSS Easy AdSense Lite – 6.06
  • XSS WordPress Social Media Widget Plugin 3.1, 3.2, 3.3 , 4.0

Deinstallieren Sie alle nicht benötigten Plugins, wie z.B die Plugins Update WP Super Cache und W3TC, welche aktuell massive Sicherheitslücken in sich bergen.
Auch auf dem Webserver selber, sollten Sie alle nicht benötigten Programme stoppen und deaktivieren. Stoppen Sie diese und den Autostart nach einem Reboot mit dem Befehl “chkconfig <Dienstname> stop“.

Zugangsbeschränkung:
Verhindern Sie das “Bruteforcen” von Passwörtern für den Administrationsbereich, beispielsweise durch die Installation des Plugins Limit Login Attempts. Installieren Sie zusätzlich das Google Authentification Plugin, um eine Zwei-Faktor-Authentifizierung einzuführen.

Konfigurieren Sie das Auto-Update Plugin, dass für Standardwordpress Versionen ab WordPress 3.4 vorgesehen ist. Hiermit patchen Sie vermeintliche Sicherheitslücken automatisch.

Nutzen Sie das SFTP Protokoll für Dateitransfers, da es auf SSH aufbaut und verzichten Sie nach Möglichkeit auf die Nutzung eines FTP Servers. Unter Windows funktioniert der SFTP-Zugriff z.B. mit dem kostenlosen Tool WinScp, unter Gnome mit Nautilus, unter KDE mit Konqueror und dem Fish-Protokoll, auf dem Mac via Cyberduck aus dem App-Store. Deaktivieren Sie den Passwort-Login auf Ihrem Linux-Server und steigen Sie um auf Public-Keyauthentifizierung.

Sollten Sie FTP nutzen, jailen Sie diesen, indem Sie eine Positiv-Liste für erlaubte Nutzer einrichten und konfigurieren Sie FTPS. Wir empfehlen hier Vsftpd, den “Very Secure File Transfer Protocol Daemon“. Berücksichtigen Sie bei der Nutzung von FTP unsere Tipps zum Thema Richtlinien zur Verwendung sicherer Passwörter.

Stellen Sie sicher, dass Ihre MySQL-Datenbank keinen Zugang auf Netzwerkebene zur Verfügung stellt. Die Datenbank sollte nicht im SafeMode laufen und ein Portscan mit dem Parameter “nmap ihrserver.de -p 3306” sollte Ihnen den Status “3306 / tcp filtered mysql ” zurückliefern. Besuchen Sie für weiterführende Informationen zu MySQL die Handlungsempfehlungen aus der Symantec Community.

Nutzen Sie an Ihrem Arbeitsplatz eine feste IP, empfiehlt es sich den administrativen Zugang auf diese eine IP mittels .htaccess zu beschränken. Legen Sie hierfür die Datei /wp-admin/.htaccess in Ihrem WordPress Verzeichnis an, falls diese nocht nicht besteht.

touch /var/www/wp-admin/.htaccess

Tragen Sie folgende Anweisungen in die Datei ein, wobei in diesem Beispiel die 22.22.42.23 Ihre statische IP ist:

order deny,allow
deny from all
allow from 22.22.42.23 
Schadensbegrenzung für den Fall eines Einbruchs:
Sollten Sie einen neuen Blog aufsetzen, vergeben Sie ein anderes Table Prefix, als die vorgegebene “wp_“.
Dies ist zwar kein starker Schutz, bewahrt Sie aber vor vielen automatisierten Attacken. Auch eine nachträgliche Änderung der Prefixe ist möglich, allerdings verzeiht WordPress womöglich bei einer Fehlkonfiguration den Fehler nicht und stellt seinen Dienst ein. Nutzen Sie, falls Sie mehrere Blogs verwalten, verschiedene Verwaltungsbenutzer und Passwörter für die WordPress-Datenbanken.

Stellen Sie sicher, dass Sie einen Einbruch bemerken. Nutzen Sie beispielsweise ein Einbruchserkennungssystem, wie PHPids.
Installieren Sie das MySQLDumper-Plugin. Dieses bietet eine sehr komfortable Möglichkeit zur Sicherung und Wiedereinspielung Ihrer MySQL-Datenbanken. Das MySQLDumper-Plugin besticht durch seinen Funktionsumfang, da Sie die Datenbanken als Ganzes exportieren können.

TIPP: Überspringen Sie den folgenden Punkt, wenn Sie eher unerfahren in der Serveradministration sind, da das Plus an zusätzlicher Sicherheit nicht allzu groß ist.

Erstellen Sie, wie in der nachstehenden Abbildung veranschaulicht, einen administrativen Benutzer und benennen Sie diesen anschließend um.

wp-admin-new user

wp-admin-new user

Testen Sie den Login mit dem neuen User und löschen Sie danach den User “admin”. Testen Sie den neuen Useraccount unbedingt auf administrative Verwaltungsrechte, sonst verlieren Sie evtl. die Kontrolle über Ihren Blog.

Befürchten Sie Einschränkungen der WordPress-Funktionen bei dem Löschen des Benutzers “admin”, vergeben Sie für diesen ein sehr komplexes Passwort und nutzen Sie diesen nicht mehr. Der Schritt der Umbenennung des “admin” Accounts ist über PhpMyAdmin oder die Datenbank selber möglich.

In der Mysql Konsole geben Sie hierfür folgendens ein:

UPDATE wp_users SET user_login = 'newuser' WHERE user_login = 'admin';

Notfallstrategie und Notfallvorsorge:
Erstellen Sie regelmäßig Backups, speichern Sie diese nicht auf dem gleichen Server und testen Sie dessen Funktionalität. Nutzen Sie, falls Sie mehrere Blogs verwalten, verschiedene Verwaltungsnutzer und Passwörter für die Wordpress-Datenbanken. Halten Sie Ihre VollBackups ruhig etwas länger vor als nötig, bemerken Sie den Einbruch erst spät, benötigen Sie ebenfalls ein weit zurückliegendes Backup.

Erstellen Sie eine Handlungsanweisung für den Notfall. Wissen die entsprechenden Mitarbeiter, wie ein Backup wieder einzuspielen ist? Haben Ihre Mitarbeiter die entsprechenden Berechtigungen?
Nutzen Sie Best-Practice-Guides zum Thema PHP-Hardening und nutzen Sie den Suhoshin Patch.

Wer sich eingehender mit dem Thema WordPress Hardening beschäftigen möchte, dem empfehlen wir die WordPress Security Checklist, die man nach einer Registrierung für den englischen WordPress Security Newsletter als Download-Link erhält.

Bedenken Sie, dass die Installation zusätzlicher Software immer ein Potential für neue Sicherheitslücken birgt. Sicherheitsplugins können somit genau das bewirken, was hätte verhindert werden sollen: Die Kompromittierung des Servers.

Fazit: Auch die Härtung eines Servers ist kein Garant für 100%ige Sicherheit, führt Sie aber näher an diesen Zustand heran. Nutzen Sie den Webseiten-Check unter http://www.initiative-s.de, der Ihre Webseite auf bösartige Veränderungen hin untersucht.

2 thoughts on “WordPress: Härtung unter Linux”

  1. Ein paar Anmerkungen:

    Limit Login Attempts ist bei derzeit ca. 90.000 Zombies, die einen verteilten Angriff auf den Login starten, sinnfrei, wenn das Passwort schwach ist. Da ist die 2-Faktor-Authentifizierung sicher der bessere Rat. Was auch hilft, ist das Vorschalten eines Passwortschutzes auf .htaccess-Ebene.

    Eine Härtung durch das Anlegen eines neuen Benutzers und Löschen des Users Admin halte ich für nicht ausreichend. Das Problem ist nämlich, dass der Username dann immer noch mit http://domain.com/?author=1 ausgelesen werden kann, weil WordPress leider defaultmäßig den Loginnamen mit dem sogenannten user_nicename gleichsetzt, der über obigen URL oder in vielen Themes auch im Quellcode auslesbar ist, wenn man mit dem entsprechenden Account kommentiert oder schreibt. Daher ist zu raten, etwa über phpmyadmin gleich nach der Installation in der Tabelle praefix_users den Wert der Variable user_login zu ändern. Damit setzt man den Loginnamen anders als den Nicename. Negative Konsequenzen hat das keine, es schützt aber zuverlässig davor, dass der Loginname ausgelesen wird.

    Was man mit initiative-s.de untersuchen kann, ermöglicht übrigens auch das Plugin Wordfence mit seinem sehr guten Scan.

    Last but not least: suhosin ist leider ab PHP 5.4 broken. Bis 5.4.4. (?) gab es noch einen Patch, der aber mittlerweile nicht mehr funktioniert

Kommentare sind geschlossen.