Oder auch Über 35 Möglichkeiten zur Sicherheit bzw. Absicherung eines WordPress Blogs um auf den X-Wege-Für-Hype aufzuspringen.…

In den letzten Wochen gab es so einige Berichte über gehackte WordPress-Installationen, oftmals wurden von Angreifern Beitragsinhalte verändert, Spamlinks eingefügt und per CSS versteckt, in anderen Fällen werden alle Beiträge gelöscht – der Ideenreichtum von Angreifern / Hackern / Spammern ist scheinbar unermesslich. Dieser Beitrag soll eine ausführliche und auch in Zukunft aktuell gehaltene Auflistung / Übersicht von Sicherheitsmassnahmen inklusive weiterführender Links zum Thema Sicherheit für WordPress bieten mit welchen vielen Angriffsversuchen schon im voraus ein Riegel vorgeschoben werden kann.

Auf der Suche nach Schutz oder Absicherung für ein WordPress Blog finden sich viele, viele Seiten die einen oder mehrere Schutzmechanismen beschreiben, selten aber eine Übersicht vieler Schutztechniken. Zu den ausführlichen Beiträgen / Listen gehört definitiv das Secure-WP-WhitePaper(PDF, dt.) und der Beitrag WordPress sicherer machen von Frank Bueltge, auf dessen Beiträge ich hier auch immer wieder zurückkommen werde. Mit diesem Beitrag möchte ich Benutzern die ihr Blog absichern wollen eine schnelle Übersicht der Suchergebnisse / Recherche bzw. Möglichkeiten zur Absicherung einer Wordpressinstallation bieten.

Inhaltsverzeichnis

• Sicherheit per Datenbank/MySQL

• Sicherheit auf Dateiebene

• Sicherheit per .htaccess-Datei

• Sicherheit in Themes

• Sicherheit per Plugin oder functions.php

• Allgemeine Sicherheitstips

• Weiterführende Links

Sicherheit per Datenbank/MySQL

• Datenbanktabellen umbenennen

  Im Normalfall beginnen die Namen aller WordPress-Datenbanktabellen mit dem Prefix wp_. Nachdem die Namen der Tabellen bekannt sind wird so ein MySQL-Injection-Angriff vereinfacht. Ändert man das Prefix z.B. mit dem Prefix Changer Plugin muss ein Angreifer erheblichen Mehraufwand betreiben um Datenbankeinträge zu verändern.

  Bei einer Neuinstallation von WordPress ist ein geändertes Prefix sehr einfach durch Ändern des Prefix in der Datei wp-config.php möglich:

  $table_prefix  = 'wp_'

  Ändern Sie die Zeichenfolge auf ein Prefix Ihrer Wahl, WordPress wird bei der Installation das neue Prefix automatisch verwenden.

  Nachträgliches Ändern des Prefix ist etwas komplizierter da WordPress das Prefix an mehreren Stellen in der Datenbank speichert, hier kann man entweder dass o.g. Plugin verwenden oder die Änderungen wie z.B. ausführlich im Secure-WP-WhitePaper(PDF, dt.) per Hand durchführen.

• Username ändern

  Der Benutzername admin einer Erstinstallation ist ebenso bekannt und wird gerne für Angriffe benutzt – Ändern des Benutzernamens führt zu Mehraufwand für den Angreifer.

• Standardpasswort ändern

  Das Standard-Installationspasswort ist bekannt und sollte schnellstmöglich im Adminmenü geändert werden.

• User-ID ändern

  Auch die ID (1) des angelegten Admin-Benutzers ist bekannt und wird bei MySQL-Injection-Angriffen z.B. zwecks Änderung des Adminpasswortes benutzt. Zur Änderung der ID kann beispielsweise ein neuer Benutzer mit Administratorrechten angelegt und der alte Admin-Account gelöscht werden. Je nachdem wieviele Benutzer zwischenzeitlich angelegt wurden verschiebt sich die ID automatisch.

• Datenbankbenutzerrechte ändern

  Sofern die Möglichkeit besteht können die Rechte eines Datenbankbenutzers auf die nötigsten Queries beschränkt werden welche von WordPress benutzt werden. AUf diese Weise lassen sich die Möglichkeiten eines eingedrungenen Angreifers in der Datenbank einschränken.

Sicherheit auf Dateiebene

• SECRET_KEY in wp-config.php einfügen/ändern

  In WordPress wurde mit der Version 2.5 der Eintrag SECRET_KEY in der Datei config.php der Installation eingefügt. Dieser Code dient der zusätzlichen Absicherung von WordPress Cookies und sollte auf einen möglichst komplizierten, eigenen Wert geändert werden. Nach Updates alter WordPress-Versionen fehlt der Eintrag völlig (sofern die alte config.php behalten wurde) und sollte ergänzt werden:

  define('SECRET_KEY', 'hier-bitte-eine-möglichst-komplizierte-zeichenkette-einsetzen');

  Weitere Informationen und einen Link zu einem Key-Generator lassen sich z.B. hier finden.

• Fehlermeldungen deaktivieren

  Ist (ab WP 2.3.1) in der wp-config.php die Zeile

  define('WP_DEBUG', true);

  vorhanden so gibt WordPress beim Seitenaufruf ggf. Fehlermeldungen aus die von einem Angreifer analysiert und durch Rückschlüsse ausgenutzt werden können. Ist er während der Entwicklung hilfreich so sollte dieser Wert auf false gesetzt werden sobald ein Blog online geht. Ältere WordPress-Versionen können durch die Zeile

  error_reporting(0);

  in der config.php bzgl. Fehlermeldungen zum Verstummen gebracht werden. Eine weitere Möglichkeit wäre stattdessen nur die Anzeige von Fehlermeldungen zu unterbinden und bei bedarf die Nachrichten in der Logdatei für Fehlermeldungen des Servers zu erhalten, das gelingt mit zwei Zeilen in der Datei .htaccess:

  php_flag display_errors off
  php_flag log_errors on

• Restriktive Datei- und Verzeichnisrechte setzen

  WordPress benötigt nicht für alle Dateien und Verzeichnisse Schreibrechte. Mit dem Setzen angemessener Rechte wie z.B. in den WordPress.org: Changing File Permissions kann man den Zugriff auf Dateien leicht einschränken, ein FTP-Programm kann im Normalfall Rechte in Zahlenform oder per Checkbox-System setzen. Durch eingeschränkte Rechte wird es einem Angreifer erschwert Dateien oder Verzeichnisse zu verändern.

  Cave: Manche Verzeichnisse benötigen bestimmte Rechte um die korrekte Funktionalität zu gewährleisten, so kann WP ohne entsprechende Rechte der .htaccess im Hauptverzeichnis Permalinks nicht automatisch neu initialisieren, /wp-content/uploads muss von WP beschreibbar sein, wp-content/backups für das Plugin BackupWordPress. Hier gilt es zu testen und ggf. die Rechte entsprechend anzupassen.

• disallow in robots.txt für interne Verzeichnisse

  Um zu verhindern das die Inhalte interner Verzeichnisse ungewollt und aus welchen Gründen auch immer in Suchmaschinenergebnisse wandern lassen sie sich für einige Suchmaschinen (Voraussetzung: sie berücksichtigen die robots.txt-Datei) Verzeichnisse vom Spidern ausschliessen.Die Datei robots.txt im Hauptverzeichnis sollte folgende Zeile enthalten:

  Disallow: /wp-

• index.php in Unterverzeichnissen

  Eine einfache aber zeitaufwändige Methode ein Auflisten von Verzeichnisinhalten bei Aufruf zu verhindern ist das Einfügen einer leeren index.php in alle Unterverzeichnisse sofern nicht vorhanden, zumindest aber im Verzeichnis /wp-content/plugins. Beim Aufruf eines Verzeichnisses wird dann statt einer Auflistung aller enthaltenen Dateien und Verzeichnisse bevorzugt diese (leere) Datei ausgegeben – fertig. Achten Sie darauf bereits bestehende index.php-Dateien nicht zu überschreiben, nur Verzeichnisse die keine solche Datei enthalten sollten die leere Variante bekommen.

• install.php und upgrade.php löschen

  Auf vielen Installationen sind die genannten Dateien im Verzeichnis /wp-admin auch nach der Installation noch vorhanden und ohne andere Schutzmechanismen wie z.B. .htaccess-Methoden für Besucher von aussen frei aufrufbar. Bevor jemand anfängt mit diesen Dateien Blödsinn zu machen sollte man sie löschen, bei einem Update werden sie automatisch wieder per Upload neu angelegt.

• Ordner /wp-content auslagern oder umbenennen

  Mit WordPress 2.6 wurden zwei neue Konstanten eingeführt, WP_CONTENT_DIR und WP_CONTENT_URL. Mit diesen beiden Konstanten lässt sich der Ordner /wp-content wenn vom Provider ermöglicht auch ausserhalb des WordPress-Installationsverzeichnisses platzieren und ausserdem frei umbenennen – ein grosses Plus an Sicherheit für WordPress da Angreifer nicht mehr auf bekannte Verzeichnisstrukturen zurückgreifen können. Ein ausführliches Tutorial hierzu ist mit Frank Bueltges Artikel WordPress 2.6 erlaubt das AUslagern von wp-content zu finden.

Sicherheit per .htaccess – Datei

• .htaccess selbst absichern

  Bei Verwendung von .htaccess sollte die Datei selbst auch abgesichert werden. Informationen hierüber findet man schön erklärt (engl.) bei PerishablePress.

• Verzeichnisansicht deaktivieren (Option -Indexes)

  Diesbezüglich ungesicherte Serverumgebungen geben beim Aufruf der URL domainname-bitte-anpassen/wp-content/plugins/ eine Übersicht der in diesem Verzeichnis befindlichen Dateien und Unterverzeichnisse, d.h. eine Liste der installierten Plugins. Potentielle Angreifer können so vulnerable Plugins aufspüren und Sicherheitslücken gezielt ausnutzen. Ändern lässt sich das mit einer Zeile in der Datei .htaccess die sich im Haupverzeichnis Ihrer WordPress-Installation befinden muss:

  Options -Indexes

  Dadurch wird beim Verzeichnisaufruf eine Fehlermeldung ausgegeben, der interne Zugriff funktioniert weiterhin.

• Datei wp-config schützen

  Wie z.B. hier zu lesen ist kann man die Konfigurationsdatei in der Datenbankzugangsdaten und Datenbanktabellenprefix enthalten so schützen:

  
  Order deny,allow
  deny from all
  

• Selektiv USER_AGENTS oder IPs aussperren

  Kennt man aus Logfiles oder Statistikplugins den USER_AGENT oder die IP eines Angreifers kann man diese(n) folgendermassen aussperren:

  RewriteBase /
  RewriteCond %{HTTP_USER_AGENT} libwww-perl.*
  RewriteRule .* - [F,L]
  

  Hier ist der USER_AGENT libwww-perl, gefolgt von irrelevanten weiteren Zeichen. Das Coreblog wurde wiederholt von einem solchen UA angegriffen der so erfolgreich ausgesperrt wurde und nicht mehr in den Logfiles auftaucht.

• /wp-includes und /wp-content schützen

  Mit folgendem Codeausschnitt kann der Zugriff über die Verzeichnisse wp-content und wp-includes auf einige wenige Dateitypen beschränkt werden:

  Order Allow,Deny
  Deny from all
  
  Allow from all
  
   Allow from all
  

  Wie bei Frank Bueltge oder auch auf blogsecurity.net beschrieben kann es nötig sein die Freigaben an Plugin- oder WordPress-Notwendigkeiten anzupassen, wenn ich mich richtig erinnere war bei WP 2.5 auch für den TinyMCE die js/tinymce Anpassung nötig wie in den blogsecurity-Kommentaren angemerkt. Eine alternative Methode für die Reaktivierung des WYSIWYG-Editors gibt es hier. Der Ausschnitt kommt in eine .htaccess-Datei innerhalb der entsprechenden Verzeichnisse und erlaubt nur Zugriffe auf XML/CSS/JPG/JPEG/PNG/GIF- ind Javascript-Dateien. Wie immer – unbedingt testen.

• Externer Zugriffe auf PHP-Dateien blockieren

  Eine Methode die sich auf dem Coreblog bewährt hat – Zugriffe auf PHP-Dateien von ausserhalb der WordPress-Installation werden geblockt. In die .htaccess-Datei des Hauptverzeichnisses wird folgendes eingefügt:

  RewriteCond %{QUERY_STRING} !error
  RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(wp-includes|wp-content)/(.+)\.php\ HTTP/
  RewriteRule .* - [F]

• Böse Querystrings filtern

  Viele Angriffe werden von automatischen Bots durchgeführt die beim Aufruf einer Seite verdächtige Texte an die URL anhängen die die Protokollidentifikatoren ftp:, http: und https:enthalten. Mit solchen Aufrufen kann versucht werden externe Scripts in die angegriffene Seite einzubinden. Wird ein solcher Querystring nicht benutzt so kann man ihn per .htaccess folgendermassen ausfiltern:

  
   RewriteCond %{QUERY_STRING} ftp\:   [NC,OR]
   RewriteCond %{QUERY_STRING} http\:  [NC,OR]
   RewriteCond %{QUERY_STRING} https\: [NC]
   RewriteRule .* -                    [F,L]
  

• IP-Zugriffsbeschränkung für /wp-admin

  Sollte man zu den wenigen Benutzern gehören die immer eine gleiche IP-Adresse für den Zugriff auf den Adminbereich benutzen kann man den Zugriff mit einer .htaccess-Datei im /wp-admin-Verzeichnis auf diese IP beschränken:

  Order deny,allow
  Allow from xxx.xxx.xxx.xxx 
  Deny from all

  Die xxx-Kombination muss durch die benutzte IP-Adresse ersetzt werden.

• Passwortschutz für /wp-admin

  Eine zusätzliche Sicherheitsschicht für bietet ein serverseitiger Passwortschutz für dieses Verzeichnis. Das Plugin AskApache Password Protect legt einen solchen Passwortschutz automatisch an. Für die handgetippte Variante gibt es unzählige Anleitungen im Netz der Netze, z.B. hier oder wieder bei Frank.

Sicherheit in Themes

• Niemals ungefilterte Benutzereingaben

  Als Themeentwickler oder auch interessierter Themebenutzer sollte man zum Thema Sicherheit beachten dass niemals ungefilterte Benutzereingaben aus z.B. Formularfeldern wie dem Suchformular ausgegeben werden – prädestinierte Angriffsziele für XSS-Attacken. Um eine sichere Ausgabe dieser Daten zu ermöglichen (z.B. ein ‘Sie haben nach xyz gesucht’ o.ä.) sollten die entsprechenden Variablen mit der Funktion wp_specialchars() unschädlich gemacht werden.

Sicherheit durch Plugins oder functions.php

• WordPress Version unsichtbar machen

  WordPress verrät in Theme- und Feeddateien jedem interessierten Nutzer die verwendete Version und damit auch die bekannten Sicherheitslücken. Um das zu verhindern gibt es das WordPress Login Sicherheit welches einerseits die Versionsinformationen entfernt, andererseits auch noch unerwünschte Fehlermeldungen im Loginbereich unterdrücken kann und im Pluginverzeichnis eine Datei index.php anlegt um möglicherweise machbares Auflisten der installierten Plugins durch Fremde zu verhindern.

• RoleManager-Plugin + Administrator+Autoren…

  Mit dem Role Manager Plugin lassen sich die Rechte einzelner Benutzer sehr detailiert einstellen. Auf diese Weise lassen sich ein Administrator mit komplizierterem Benutzernamen und Passwort für selten benutzte Aufgaben benutzen dessen Account nicht so leicht geknackt werden können sollte und ein Benutzer für den Alltagsgebrauch mit einfacher Benutzername / Passwort-Kombination zum schreiben / editieren von Beiträgen und Freischalten / Schreiben von Kommentaren.

• Regelmässige Backups von Dateien und Datenbank

  Wichtig, wichtig, wichtig: Ein hablbwegs aktuelles Backup der WordPress-Installation, Theme-Dateien und Datenbankinhalte kann das Blog nach geglücktem Angriff wiederherstellen falls keine anderen Möglichkeiten zu Verfügung stehen. Bewährt hat sich hier z.B. BackupWordPress auf designpraxis.at mit welchem automatisiert und regelmässig Backups aller Dateien und / oder Datenbankinhalte auf dem Webspace gespeichert (es wird automatisch eine .htaccess in diesem Verzeichnis angelegt die Zugriffe von aussen verhindern soll, trotzdem empfehle ich Backupdateien nicht allzu lange auf dem Server liegen zu lassen da sie sensible Daten enthalten) und optional (meine bevorzugte Methode) auch per Email an den Admin gesandt werden.

  Ein Alternativplugin wäre WP-DB-Backup welches im Gegensatz zu BackupWordPRess ausschliesslich die WordPress-eigenen Datenbanktabellen und optional zusätzliche (z.B. von Plugins verwendete) Tabellen als Backup per Mail verschickt. So kann man z.B. grosse Tabellen von Statistikplugins vom Backup ausschliessen. Um das Backup der Dateien auf dem Server muss man sich hier allerdings selbst kümmern, was per (s)FTP allerdings auch kein Problem darstellt.

• IP-Lock-Schutzmechanismus für fehlerhafte Loginversuche

  Login LockDown zählt fehlerhafte Loginversuche, blockiert je nach Anzahl die entsprechenden IP-Adressen und verhindert so Brute-Force-Attacken von statischer IP-Adresse.

• Login-Fehlermeldungen unterdrücken

  Frank Bueltge hat ein weiteres Plugin veröffentlich (alternativ eine Zeile Code in der functions.php) mit welchem sich einfach die Fehlermeldungen im Loginformular unterdrücken lassen. Sinn ist ähnlich wie beim Unterdrücken der PHP-Fehlermeldungen und -Warnungen, ohne Rückmeldung kann ein Angreifer keine Fehleranalyse durchführen.

• SemiSecure Login

  Mit diesem Plugin lässt sich ein kleines Plus an Sicherheit erreichen indem die Benutzerdaten des Loginformulares per Javascript schon clientseitig verschlüsselt werden statt wie normalerweise im Klartext an den Server übertragen zu werden.

• WordPress Version verstecken

  Ist dem Angreifer unbekannt mit welcher WordPress-Version er es zu tun hat so kann er nicht einfach bekannte Sicherheitslücken ausnutzen sondern muss quasi blind per Bot oder Hand ausprobieren welche Methode funktionieren könnte. Nun zeigt WordPress im META GENERATOR-Tag des Headbereiches gerne diese Informationen an, auch in den Feeds und unter dem Loginformular sind diese Informationen zu finden. Replace-WP-Version verschleiert bzw. entfernt ab WordPress 2.5 sogar diese Informationen wie Frank Bueltge hier berichtet.

• WP-Security-Scan

  Dieses Plugin kann einige Sicherheitsmassnahmen überprüfen und den Autor entsprechend benachrichtigen, unter anderem wird auf geändertes Datenbanktabellenprefix geprüft, Beschreibbarkeit des wp-content-Verzeichnisses (hier wird allerdings das Blocken von Zugriffen auf PHP-Dateien von ausserhalb des Servers nicht erkannt) und mehr…

• Exploit Scanner Plugin

  Das Exploit Scanner Plugin durchsucht Datenbank und Dateien nach potentiell verdächtigem Code. Das verhindert zwar nicht einen Angriff, hilft aber bei der mühsamen Suche nach Schadcode.

Allgemeine Sicherheitstipps

• Passwörter regelmässig ändern

  Regelmässiges Ändern der Passwörter erschwert Brute-Force-Attacken und kann missbrauch bei bereits geknacktem Passwort (wenn es sich denn noch ändern lässt) verhindern.

• Passwörter gut und sicher auswählen

  Ein gutes Passwort besteht nicht aus einfachen Wörtern, Geburtsdaten, Hochzeitsdatum o.ä., ein gutes Passwort ist nicht zu kurz, enthält Buchstaben, Zahlen und Sonderzeichen, idealerweise ohne erkennbares System. Dadurch werden Brute-Force-Attacken mit z.B. Wörterbüchern / Datum-Tabellen als Grundlage erschwert.

• WordPress aktuell halten, auf Sicherheitsupdates achten

  Mit fast jeder WordPress-Version werden Sicherheitslöcher gestopft, die dreistelligen Zwischenversionen dienen nahezu ausschliesslich der Sicherheit – halten Sie ihre WordPress-Version stets aktuell. Um über neue Versionen informiert zu bleiben empfiehlt sich z.B. der Developer Feed, das Dashboard bzw. der Adminbereich Ihrer Installation (WordPress zeigt auch hier verfügbare Updates an) oder einschlägige Internetseiten wie WordPress.Org

• Plugins aktuell halten, auf Sicherheitsupdates achten

  Durch viele Plugins können natürlich auch viele Sicherheitslöcher entstehen und ins eigene Blog eingabut werden, auch Pluginprogrammierer sind nur Menschen. Wird ein Programmierer über Sicherheitsrisiken in seinem Plugin informiert so wird er im Regelfall ein Update des Plugins veröffentlichen welches dann nur noch installiert werden muss. Nützlich ist hier die automatische Updatesuche von WordPress die auf WordPress.Org gespeicherte Plugins selbstständig auf Updates überprüft und den Admin ggf. im Plugins-Menü der Installation benachrichtigt.

• Plugin-Anzahl minimieren = Sicherheitsrisiken minimieren

  Einfach – je weniger Plugins desto wehnicher Risiko für Sicherheitslücken – und nebenbei ein schnelleres WordPress-System.

• Theme aktuell halten, auf Sicherheitsupdates achten

  Siehe Plugins aktuell halten, auch Themes können Sicherheitslücken enthalten und sollten auf aktuellem Stand gehalten werden.

• Themes-Anzahl minimieren = Sicherheitsrisiken minimieren

  Siehe Plugin-Anzahl minimieren, wer nur ein Theme benutzt braucht nicht noch X Ordner mit anderen Themes.

• sFTP statt FTP als Protokoll verwenden da Klartext-Daten verschickt.

  Bei FTP werden Benutzerdaten im Klartext über die Kette der Server bis zum Ziel übertragen, dort könnten die Daten theoretisch abgefangen und zwecks Missbrauch gespeichert werden. Durch sFTP werden die Daten vor Versandt verschlüsselt – Mehraufwand für einen potentiellen bösen Buben (oder Mädel).

Weitere Links zum Thema Sicherheit

• http://codex.wordpress.org/Hardening_WordPress
• http://codex.wordpress.org/htaccess_for_subdirectories
• http://codex.wordpress.org/Changing_File_Permissions
• http://wordpress-buch.bueltge.de/wordpress-sicherer-machen/30/
• http://wordpress-buch.bueltge.de/wordpress-templates-sicherer-machen/31/
• http://www.linickx.com/archives/342/trouble-shooting-the-wordpress-security-white-paper#comment-9366
• Effektive Sicherheit in WordPress – wp-magazin.ch
• http://www.epiblogger.net/5-wordpress-security-essentials/
• http://www.texto.de/texto/9-quick-tipps-zur-sicherheit-oder-hilfe-mein-blog-wurde-gehackt/
• http://www.askapache.com/wordpress/htaccess-password-protect.html
• http://www.reubenyau.com/protecting-the-wordpress-wp-admin-folder/
• http://www.smallbiztrends.com/2008/02/how-to-protect-your-wordpress-site.html/
• http://www.stopbadware.org
• http://lorelle.wordpress.com/2007/09/10/protecting-your-wordpress-blog/
• http://blogsecurity.net/wordpress/blogwatch/blogwatch/