Hier erfahrt Ihr, wie Ihr Euer WordPress-Instanz mittels einiger .htacces-Kniffe in eine Festung verwandeln könnt.
WordPress-Sicherheit ist ein wichtiges Thema. Webmaster, denen schon mal ein Projekt gehackt wurde, wissen wie nervig es sein kann, dieses wieder vollständig herzustellen. Ich hatte bisher auf meinen WordPress-Projekten hauptsächlich auf Plugins gesetzt, um die Sicherheit zu erhöhen. Welche Plugins ich dabei einsetze, habe ich in diesem Artikel beschrieben.
Doch als ich dieses Jahr auf der SEOCampixx in einem Vortrag von Sebastian Blum saß und er über Ransomware referierte, wurde mir bewusst, wie groß meine Sicherheitslücken noch waren. Zum Glück lieferte er in seinem Vortrag noch diverse Vorschläge, die Sicherheit zu erhöhen, gleich mit.
Ich habe diese Vorschläge dann Schritt-für-Schritt evaluiert und mich auf diversen Blogs über die Anwendung jedes einzelnen Vorschlags schlaugemacht. Nachdem ich diese nun in mehreren Blogs seit einigen Wochen laufen habe, möchte ich diese nun gerne mit Euch teilen.
Schritt für Schritt – Wie müsst Ihr vorgehen?
Zunächst einmal benötigt Ihr einen FTP-Zugriff. Ihr ruft damit Euren Webspace auf und schaut im Hauptverzeichnis der WordPress-Installation nach der .htaccess Datei. Diese öffnet Ihr mit einem Texteditor oder noch besser mit Notepad++
In der Regel findet Ihr dort einen vorhanden Eintrag, der in etwa so ausschaut.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Dieser Eintrag ist wichtig für Eure Permalinks. Daher lasst Ihr den Eintrag auch unverändert so in der Datei stehen. Die nachfolgenden Code-Tipps könnt Ihr einfach unterhalb von # END WordPress in die htaccess-Datei kopieren.
Inhalte dieses Artikels
Die Datei wp-config vor fremden Zugriff schützen
In der wp-config stehen die Zugangsdaten zu Deiner Datenbank und weitere wichtige Dinge. Wer diese Daten ausliest, kann problemlos Deine Datenbank kapern. Daher sollte man diese Datei unbedingt vor unberechtigten Zugriff schützen. Das funktioniert, indem man seine htaccess um den folgenden Code erweitert.
# Protect wp-config
<files wp-config.php>
order allow,deny
deny from all
</files>
Anschauen von Verzeichnissen verhindern
Wenn der Server nicht geschützt wird, können Unbefugte sich ganz einfach über den Webbrowser die Verzeichnisstruktur von Deinem WordPress anschauen und hier nach Sicherheitslücken suchen. Das sollte in jedem Fall verhindert werden. Normalerweise sperren die Webhoster das Verzeichnisbrowsing per Default, dann braucht Ihr nichts weiter zu machen.
Überprüfen könnt Ihr dies, in dem Ihr einfach mal versucht, mit dem Browser das Upload-Verzeichnis Eures Blogs aufzurufen, also http://www.euerblog.de/wp-content/uploads/
Erscheint hier eine Fehlermeldung mit dem Status “403 Zugriff verboten” ist alles in Ordnung. Wenn Ihr nun aber den Inhalt des Upload-Ordners angezeigt bekommt, solltet Ihr dringend den folgenden Code-Schnipsel in Eure .htaccess kopieren.
# Disable directory browsing
Options All -Indexes
Schützen des wp-includes Verzeichnisses
Dieser Unterordner beinhaltet viele PHP-Funktionen, ohne die WordPress nicht laufen würde. Von außen sollte aber niemand darauf zugreifen können. Den Ordner könnt Ihr mithilfe dieses Code-Schnippets vor fremden Zugriffen schützen
# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>
Readme und liesmich-Dateien schützen
Über den Browser kann jeder die Readme.html oder liesmich.html aufrufen. Das Problem: dort steht die derzeit verwendete WordPress-Versionsnummer. Mit dieser Info können Hacker ggf. bekannte Sicherheitslücken identifizieren, insbesondere, wenn es sich um ältere WordPress-Versionen handelt. Man kann die Dateien natürlich nach jedem Core-Update über FTP löschen, aber das ist nicht wirklich praktisch und wird sicher auch des öfteren vergessen. Viel einfacher ist es, den folgenden Code in seine .htaccess zu kopieren:
# PROTECT readme.html
<files readme.html>
Order Allow,Deny
Deny from all
Satisfy all
</Files>
# PROTECT liesmich.html für DE Edition
<Files liesmich.html>
Order Allow,Deny
Deny from all
Satisfy all
</Files>
Testen könnt Ihr die Wirksamkeit des Snippets, in dem Ihr einfach nochmal versucht, die readme.hml oder die liesmich.html über einen Webbrowser aufzufrufen. Das sollte jetzt nicht mehr möglich sein.
xmlrpc.php schützen
Leider wird diese Schnittstelle immer wieder von Spammern missbraucht, die darüber DDoS-Attacken gegen andere fahren. Außerdem sollen sich Angreifer über die Schnittstelle Zugriff auf das WordPress-Backend verschaffen können. Daher sollte man die Schnittstelle mit diesem Code deaktivieren.
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
Wer seinen WordPress-Blog hinter einem Content-Delievery-Network wie Cloudflare betreibt, kann hier auch noch eine ergänzende Maßnahme ausführen. Unter dem Punkt “Page Rules” kann eine Regel erstellt werden, die bei jedem Aufruf der xmlrpc-Datei einen Security-Check vollzieht.
Mit dieser Regel hält man die Last weg vom eigenen Server. Denn die oben genannte Apache-Regel in der .htaccess verhindert ja nicht die Server-Anfragen, sondern nur, dass die Anfragen auch bis zu der xmlrpc-Datei durchgeleitet werden. In der Regel beschießen Spammer die Schnittstelle jedoch tausendfach bis sie dann merken, dass sie nicht durchkommen. Hier kann Euer Server schon mal in die Knie gehen. Mit der aktiven Cloudflare-Regel kommen die Anfragen gar nicht bis zu Eurem Server durch, sondern bleiben in der Cloudflare-Firewall hängen.
Für alle die noch nicht wissen, wie Cloudflare funktioniert bzw. wie man es im Zusammenspiel mit WordPress einrichtet, habe ich hier einen Artikel dazu verfasst.
Auf den Nachteil dieser Deaktivierung möchte ich aber auch noch hinweisen. Leider werden nun keine Trackbacks mehr von anderen Blogs empfangen und unter den Artikeln ausgegeben.
wp-login vor fremden Zugriff schützen
Ein Einfallstor für Hacker ist natürlich auch der Admin-Zugang über /wp-login/. Hier könnten z.B. Brute-Force Attacken gestartet werden, um die Zugangskombination zu knacken. Auch wenn die Hacker dabei vielleicht nicht zum Ziel kommen, können die Attacken trotzdem mindestens Euren Server lahmlegen. Am besten man schützt den Admin-Bereich durch ein zusätzliches Passwort.
<Files wp-login.php>
AuthType Basic
AuthName "Members Only"
AuthUserFile /pfad/zur/.htpasswd
Require valid-user
</Files>
Weil es bei dieser Methode zu Poblemen bei der Ausführung von Ajax kommen kann, sollte der obige Code-Snippet noch um die folgende Ausnahme ergänzt werden.
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>
Die Vorgehensweise ist dabei wie folgt:
Wenn mit dem Browser /wp-admin/ aufgerufen wird, erscheint ein Authentifizierungsfenster, welches einen Benutzernamen und ein Passwort abfragt. Die eingegebenen Daten werden mit denen in einer .htpasswd Datei abgeglichen. Bei Übereinstimmung wird die Seite /wp-login/ im Browser geöffnet.
Wir benötigen also noch eine .htpasswd-Datei und müssen außerdem den relativen Pfad zu dieser Datei in der .htaccess hinterlegen. Zur Erzeugung der .htpasswd-Datei öffnen wir mit einem Texteditor eine leere Datei und kopieren den Inhalt eines htpasswd-Generators hinein. Dann die Datei als .htpasswd abspeichern und per FTP auf Euren Server kopieren.
Nun zum relativen Pfad. Normalerweise ist einem der relative Pfad auf dem Server des Hosters nicht bekannt. Den kann man aber leicht herausbekommen, wenn man wieder einen Texteditor nimmt und folgenden Code in eine leere Textdatei schreibt.
<?php
$dir = dirname(__FILE__);
echo "<p>Full path to this dir: " . $dir . "</p>";
echo "<p>Full path to a .htpasswd file in this dir: " . $dir . "/.htpasswd" . "</p>";
?>
Die Datei dann als “fullpath.php” abspeichern und wieder per FTP in das Verzeichnis kopieren, in dem auch die Passwortdatei .htpasswd liegt. Nun mit dem Browser die fullpath.php aufrufen. Wenn die im Hauptverzeichnis liegen sollte, dann wäre dies http://www.euerblog.de/fullpath.php
Ihr erhaltet nun im Browser den Pfad zur .htpasswd angezeigt und könnt diesen in die .htaccess kopieren. Nach dem Vorgang die fullpath.php wieder von Eurem Server löschen!
Deaktivieren der PHP-Errorlogs
Fremde sollten auch kein Zugriff auf PHP-Fehlermeldungen gegeben werden. Mit diesem Snippet könnt Ihr das Aulesen der Errorlogs verhindern.
<files error_log>
Order allow,deny
Deny from all
</files>
Schützen der .htaccess
Zuguterletzt sollte man die .htaccess selbst vor fremden Zugriff schützen. Sonst könnten Hacker ja all die schönen Sicherheitscodes wieder löschen und das wollen wir natürlich nicht.
# STRONG HTACCESS PROTECTION
<Files ~ "^.*\.([Hh][Tt])">
order allow,deny
deny from all
satisfy all
</Files>
Wenn Ihr Eure Webseite in der Google Search-Console aktiviert habt und dafür eine HTML-Datei zur Bestätigung in Eurem Root-Verzeichnis hinterlegt habt, solltet Ihr noch dieses Snippet in die .htacces kopieren.
<FilesMatch "name_der_googledatei.html">
Satisfy Any
Allow from all
</FilesMatch>
Dann bleibt gewährleistet, das Google diese Datei weiterhin aufrufen kann.
Ich habe die vorgestellten Code-Snippets in sämtlichen von mir betriebenen WordPress-Blogs in die .htaccess eingetragen und bisher nirgendwo Probleme feststellen können. Das subjektive Sicherheitsgefühl ist dabei aber besser geworden. 🙂
Wenn Euch die hier vorgestellten htaccess-Snippets gefallen, postet es doch gerne in die Kommentare. Wenn Ihr sie übernommen habt und in Eure .htaccess eingebaut habt, freue ich mich auch gerne über die Erfahrungen, die ihr damit gemacht habt. Kennt Ihr noch andere Erweiterungen für die .htaccess, die die Sicherheit erhöhen?
Bitte sozial teilen
Wenn dir dieser Beitrag gefallen hat, dann teile ihn doch bitte in den verschiedenen sozialen Netzwerken! Du würdest mir damit sehr helfen!