Titelbild: Ilya Pavlov on Unsplash
Dieser Artikel ist eine Fortsetzung ds vorherrigen Beitrags WordPress sicher(er) machen – Schutz vor Hacking-Angriffen

[Update 01.12.2018: JSON REST API absichern // wp-login.php und passwortgeschützte Seiten]

Die Möglichkeiten, WordPress abzusichern oder performanter zu gestalten sind sehr, sehr vielfältig – ebenso wie die Angriffsmöglichkeiten. Es gibt nicht DIE EINE beste Strategie, sondern vielfältige Ansätze, von denen manche mehr Wirkung und Sinn als andere machen. Und es gibt auch unterschiedliche Vorlieben in Strategien. Ich stelle in diesem Beitrag ein paar gängige und einen Auszug eher unbekannter Anpassungen vor, von denen wir überzeugt sind.

Fairerweise sollten wir WordPress zunächst selbst auch zu Wort kommen lassen, denn schließlich geht es ja um Sicherheitsaspekte dieser Software: hier ein Codex zum Thema Sicherheit und Schwachstellen.

Präventiver Schutz

Einfach umzusetzen und schon recht sicher

  1. Sichere Passwörter
    Keine Wörter aus dem (englischen oder deutschen) Duden, mindestens 16 Zeichen, Groß- und Kleinschreibung, Ziffern, Sonderzeichen.
  2. WordPress-Username nicht admin und auch sonst nicht leicht zu erraten. Am besten auch gleich die automatische ID 1 verändern.
  3. Tabellenpräfix (idealerweise bereits bei der WordPress-Installation) ändern von wp_ nach etwas anderem, z.B. xkj_
  4. WordPress sowie sämtliche plugins immer auf dem aktuellen Stand halten. Sucuri berichtet, dass 25% der gehackten WordPress-Seiten kompromittiert wurden, weil sie veraltete Versionen eines von nur drei beliebten plugins hatten. Auch potenzielle Sicherheitslücken von deaktivierten plugins können problematisch werden. Am Besten so wenig plugins wie möglich verwenden (und löschen oder unerreichbar machen!) und die Bewertungen und letzten Entwicklungszeitpunkt berücksichtigen.
  5. Ein gutes und sinnvolles(!) Standard-Sicherheitsplugin verwenden und passend konfigurieren kann noch Zusatznutzen bringen.
  6. Zugriffsrechte auf Verzeichnisse (755) und Dateien (644) im Allgemeinen restriktiv halten.

Das Wichtigste: Backups!

Es kann nicht oft genug wiederholt werden: schlimmer als eine gehackte oder gecrashte Webseite ist, wenn man kein wiederherzustellendes Backup hat!

Mit diesen Punkten kann man nichts wirklich falsch machen (bis auf eine inkompatible Fehlkonfiguration eines Sicherheitsplugin) und sie bringen bereits ganz ordentliche Sicherheit verglichen mit dem vermuteten Durchschnitt aller WordPress-Installationen. Der Aufwand und die benötigte Expertise sind überschaubar.

Einfache Tricks aus der Profikiste

Je komplexer eine Webseite und je „bedeutsamer“ die Anwendung (ein einfacher Blog vs. eine Verkaufsplattform inkl. Forum), umso wichtiger werden Sicherheitsaspekte. Gleichzeitig möchte man aber auch nicht den Komfort einschränken oder die Performance zurückfahren.

Um sich für ein paar sinnvolle Eingriffe zu entscheiden, betrachten wir daher diejenigen Anpassungen, die nicht nur Sicherheit, sondern zusätzlich auch Performance bieten.

In diesem Zusammenhang ist natürlich ebenso wichtig zu schauen, an welcher Stelle die größten Angriffe erfolgen, dort setzen wir an. Wer neben der Basisabsicherung die nachfolgenden Punkte in seine Strategie einarbeitet, wird vermutlich keine Probleme mit Angriffen haben.

Schwachstelle #1: die Datei wp-login.php und JSON REST API

Betrachte man seine Webseitentraffic, so wird man feststellen, dass immer wieder Aufrufe stattfinden, die nicht zur eigentlichen Webseitenstruktur zählen. Darunter sind Direktaufrufe zu vermuteten plugins, die gar nicht installiert sind (z.B. http://meine-domain.com/wp-content/plugins/irgendeinplugin/uploadify.php), mit der schwachen Hoffnung, dort möge jenes plugin installiert und noch mit der bekannten, nicht geschlossenen Sicherheitslücke nur darauf warten, vom aufrufenden Bot missbraucht zu werden.

Die Datei, die jedoch vermutlich am meisten von Hacker-Bots „ausprobiert“ wird, ist die Datei wp-login.php, die wir zur Anmeldung im WordPress-Backend benötigen. Sie ist besonders heikel und bedarf daher besonderen Schutzes. Die eleganteste und wirksamste Art, dies zu tun, ist allerdings nicht etwa ein Redirect, wie es z.B. über das plugin WPS Hide Login angeboten wird. Gar nicht mal schlecht und auch komfortabel, ich möchte hier allerdings kurz die viel sicherere Methode per Webserver-Konfigurationsdatei .htaccess empfehlen.

[Bitte aber auch die Hinweise weiter unten zu passwortgeschützten Seiten beachten!]

Diese Datei wird vom Webserver interpretiert bevor php-Programme wie WordPress ausgeführt werden. Es ist unser erstes Bollwerk gegen Angreifer und entlastet damit die php-Engine und WordPress, weil nicht autorisierte Zugriffe von vornherein geblockt werden. Diese Vorgehensweise bedeutet also nicht nur mehr Sicherheit, sondern auch mehr Performance.

Man legt dazu einen Zugriffsschutz auf diese Datei, die anschließend nur noch über Benutzername & Passwort – Authentifizierung erreichbar ist. Gleichzeitig werden auch nicht angemeldete Besucher von wp-admin dorthin umgeleitet, so dass auch dies abgesichert ist. Dazu erstellen wir eine, idealerweise in einem höheren Verzeichnis liegende, Datei .htpasswd mit verschlüsseltem Passwort. Die .htaccess im Hauptverzeichnis (Webroot) erweitern wir mit folgendem Code:

# Absicherung wp-login.php
<Files wp-login.php>
AuthName "Anmeldung nur fuer Berechtigte"
AuthType Basic
AuthUserFile /Pfad/zur/Datei/.htpasswd
require valid-user
</Files>

Anschließend wird WordPress über diesen Angriffspfad nicht mehr belästigt werden. Wir müssen uns allerdings quasi zweimal ins Backend einloggen, was aber zu verschmerzen sein sollte angesichts des Sicherheitsgewinns. (Ich würde von meinem Browser das .htaccess-Passwort speichern lassen, dann ist’s komfortabler.)

Und wenn wir schon die .htaccess am Wickel haben, dann können wir auch noch gleich folgende Zeilen ergänzen:

# Zugriff zu wichtigen Dateien untersagen
<FilesMatch "(\.htaccess|\.htpasswd|wp-config.php)">
Require all denied
</FilesMatch>

Dies führt dazu, dass diese sensiblen Dateien nicht mehr aufgerufen werden können, der Webserver wird dafür sorgen.

Hier eine Erklärung, wieso eine oft empfohlene Verschleierung von WordPress nichts bringt und hier eine sehr ausführliche Anleitung zur Umsetzung der vorgestellten .htaccess-Methode. Weitere sehr ausführliche Infos zu htaccess auf der Webseite AskApache.

Neu: Hinweis zu passwortgeschützten Seiten

Wenn bestimmte Seiten oder Beiträge mit dem WordPress-Passwortschutz versehen werden, dann wird der nicht angemeldete Besucher, der ganz legal auf eben jene passwortgeschützte Seite möchte, ebenfalls die .htaccess-Passwortabfrage in der wp-login.php durchlaufen müssen.

Tipp: Man könnte nun versuchen, die wp-login.php?action=postpass mittels mod_rewrite in z.B. /login/protected/ umzuwandeln, so das die htaccess Anweisung für die wp-login.php hier nicht greift. Hier mal ein Beispiel: http://stackoverflow.com/questions/2670535/htaccess-code-to-protect-a-single-url?lq=1 (Das werden wir bald testen und diesen Beitrag entsprechend anpassen)

Neu: die Ausnutzung der JSON REST API
Ebenfalls ein weiterer starker Angriffsvektor stellt die Nutzung der JSON (JavaScript Object Notation) REST (REpresentational State Transfer = Architekturstil) API (Application Programmer Interface = Schnittstelle) dar. Einfach gesagt: eine Schnittstelle zur Kommunikation mit anderen Diensten wie Twitter etc. in einfacher Notation. Diese kann leider auch von bösen Bots gelesen und ausgewertet werden. Man kann das leicht überprüfen, wenn man an die Domain anhängt /wp-json/wp/v2/users, also z.B. https://meine-domain.com/wp-json/wp/v2/users. Wenn das nicht abgesichert ist, findet man dort heikle Informationen zu den Admins wie Login-Namen und ID. Um das zu verhindern, gibt es das plugin Disable REST API mit Einstellmöglichkeiten (WhiteListing) für bestimmte Dienste, z.B. dem Kontaktformular, das ja weiterhin funktionieren soll.

Schwachstelle #2: die XML-RPC-Schnittstelle

Über die Datei xmlrpc.php (Remote Procedure Call) wird zum einen eine WordPress-interne Vernetzung ermöglicht und zum anderen kann WordPress damit über externe Programme verwaltet – und angegriffen – werden. Viele Webseitenbetreiber nutzen diese Funktion nicht, gleichwohl gehört sie zur Standardfunktionalität. Wenn sie nicht genutzt wird, sollte sie abgeschaltet werden oder wenn genutzt, zumindest reduziert werden auf die berechtigten Verwaltungsschnittstellen.

Der einzufügende Code in die .htaccess lautet:

# Zugriff verweigern für wichtige Dateien
<filesmatch "(^\.|wp-config\.php|xmlrpc\.php|(?<!robots)\.txt|(liesmich|readme)\.*)">
Require all denied
</FilesMatch>

Siehe auch https://gist.github.com/zottto/6b44eb58baf44fc6bd62 und eine sehr ausführliche Abhandlung an dieser Stelle auf kuketz-blog.de.

Schwachstelle #3: plugins, die direkt php-Code ausführen können

Die gemeinsten Schwachstellen sind installierte plugins, die unkontrolliert (da autorisiert) direkt beliebigen php-Code ausführen können. Eine der größten Lücken ist daher die dafür genutzte Datei admin-ajax.php im Verzeichnis wp-admin. Die Verwendung von Ajax nimmt zu, da es ein komfortables Gimmick ist, vom Frontend steuernd ins Backend eingreifen zu können. Immer mehr plugins und Themes nutzen diese Schnittstelle im Systemordner von WordPress.

Wird ein solches plugin kompromittiert, weil es entweder unsicher geschrieben oder nicht aktualisiert wurde und damit eine bekannt gewordenene Schwachstelle vom Bot genutzt wird, haben wir einen erfolgreichen Angriff auf unserer Installation mit möglichen weitreichenden Folgen.

Man kann sich entscheiden, unter Berücksichtiugung von verwendeten plugins und Themes auf die Ajax-Funktionalität zu verzichten und im Ordner wp-admin den Zugriff auf die Datei in der dort abgelegten .htaccess zu untersagen:

# Zugriff zu Ajax untersagen
<FilesMatch "(admin-ajax.php)">
Require all denied
</FilesMatch>

WICHTIG: Das sollte allerdings besonders gründlich getestet werden, damit nicht unentdeckte Sperren zu einem unschönen Erlebnis und einer Abwertung bei der Webseitenwertigkeit führen.

Meine Meinung: Mit dieser harten und teuer erkauften Lösung bin ich allerdings noch nicht wirklich zufrieden und suche noch weiter nach eleganteren Optionen. Eventuell könnte man die .htaccess anweisen, den Zugriff auf diese Datei nur bestimmten User-Agents zu erlauben, das hält zwar eine Menge Angriffsmüll ab, ist aber aufgrund der nicht verlässlichen Bot-Angaben unsicher.

Schwachstelle #4: die wichtigste aller Dateien, die wp-config.php

WordPress bietet die Möglichkeit die Konfigurationsdatei mit dem Generalschlüssel zur Datenbank wp-config.php aus dem Webroot vollständig auszulagern und in einem gesicherten Verzeichnis unterzubringen. Damit wäre sie unmöglich über den Webserver auszulesen. Es gibt hierüber geteilte Meinungen, wie sinnvoll das ist. Denn wenn jemand diese php-Datei lesen kann, dann ist der Angreifer ohnehin schon weit vorgedrungen. Andererseits spricht dafür, dass bestimmte Angriffsvektoren (wer kennt sie schon alle?) an dieser Hürde scheitern würden. Z.B. auch kompromittierte FTP-Zugänge.

Wen das interessiert, kann sich hier einlesen:
https://codex.wordpress.org/de:WordPress_absichern#Sichern_der_wp-config.php
https://wordpress.stackexchange.com/questions/58391/is-moving-wp-config-outside-the-web-root-really-beneficial/74972#74972

Welche (Schein-)Sicherheitsaspekte weit verbreitet, aber wenig hilfreich sind

Verstecken der wp-login.php

Es ist eine Möglichkeit, aber nicht die beste: denn es folgen immer noch Brute Force Angriffe, die WordPress beschäftigen (und tendenziell verlangsamen) und falls doch ein Bot den richtigen Login-Pfad findet, ist nichts gewonnen. WPS Hide Login wäre – wenn – hierfür geeignet. Allerdings wird damit nicht verhindert, dass eben moderne Bots auch oft über die oben erwähnte JSON Schnittstelle einfallen.

Begrenzen der Anmeldeversuche

Angreifende, professionelle Bot-Netzwerke verfügen über zig tausende Server und damit IP-Adressen. Sollte ein Anmeldeversuch scheitern, so wird dasselbe Programm mit der nächsten IP-Adresse dasselbe versuchen. Zig tausend mal. Man kann das wunderbar im Zugriffsprotokoll beobachten. Der einzige Vorteil ist, dass man unter Umständen von diesem Versuch von seinem „Sicherheitstool“ informiert wird – und man etwas Zeit gewinnt.

Die Datei robots.txt anweisen, bestimmte Bots auszusperren

Bots können sich tarnen oder als andere User-Agents ausgeben und damit vorgeben, berechtigt zu sein. Zudem ist die robot.txt nur eine Bitte an seriöse Bots, z.B. bestimmte Inhalte zu ignorieren. Wie hoch ist die Wahrscheinlichkeit, dass ein ausgebildeter krimineller Bot diese freiwilligen Hinweise befolgt?

DER Tipp für einfache Lösungen: mit HTML wartungsfrei, sicherer und schneller

Ein ganz besondere, ernsthafte Empfehlung für Webseitenbetreiber, die mit dem ganzen Kram wirklich nichts zu tun haben wollen und eine eher wenig interaktive Webseite haben ohne Kommentarfunktion, Kontaktformulare o.ä.:

  1. fast keine Wartungsaufwände mehr!
    WordPress und seine plugins müssen nicht permanent upgedatet werden und können so auch nicht untereinander in Konflikte geraten: Motto „never touch a running system!“
  2. vermutlich keinen Angriffen mehr ausgesetzt!
    über .htaccess das gesamte(!) WordPress auf eigener Subdomain absichern
  3. schnellere Ladezeiten für besseres Surferleben!
    HTML-Dateien werden nicht erst über den php-Inertpreter generiert, sondern sind sofort verfügbar und können somit schneller ausgeliefert werden.

Wie geht das? Relativ simpel. Die WordPress-Umgebung liegt z.B. in einer Subdomain, die vollständig mit .htaccess abgesichert ist. Mit dem plugin „Simply Static“ wird die Webseite dann in HTML umgewandelt und in das Produktiv-System (=die eigentliche Domain) publiziert. Fertig! Nach jeder Änderung an der Webseite wird die HTML-Version anschließend mit einem Klick neu generiert und ist dann aktuell und sofort online verfügbar.

Mit dieser Lösung sind dann natürlich keine dynamischen php-Funktionen mehr möglich wie Kommentare, feeds, Kontaktformulare etc. Wer darauf verzichten kann, dem empfehle ich diese wirklich sehr clevere Umsetzung. Dabei wäre noch zu beachten: wie die Suchmaschinen auf die neue Umgebung reagieren und das explizite Abfangen von nicht mehr existenten, weil nicht mehr benötigten php-Dateien (404er).

Neuer Hinweis [01.12.2018]: Besonders sauber wird es daher, wenn man bestimmte Seiten, die von den (guten) Bots aufgerufen werden wie (das nicht statifizierte) /feed etc. umleitet auf eine HTML-Seite. Dies geschieht einfach, indem man alle 404-Fehler pauschal abfängt: denn diese Standard-WordPress-Funktionalität für nicht gefundene Seiten steht dort auch nicht mehr zur Verfügung. Ein Eintrag in der .htaccess könnte daher so aussehen:

ErrorDocument 404 /error404.html

Sicherheit bis zum Abwinken

An dieser Stelle möchte ich diesen Artikel beenden, auch wenn es noch sehr viel mehr dazu zu schreiben gäbe, noch mehr Sicherheitsstrategien, Einstellungen, Empfehlungen etc.

Wer die Suchmaschinen bemüht und nach „WordPress absichern“ etc. sucht, wird viele sehr ausführliche Blogserien, auch auf deutsch, finden können. Man kann sich darin verlieren und man kann es übertreiben – bis zum nächsten erfolgreichen Angriff, der einen zwingt, noch mehr für die Sicherheit zu investieren.

Bis heute kann ich sagen, dass unsere Strategie, die hier zum Großteil offengelegt wurde, korrekt angewendet noch nie zu einem erfolgreichen Angriff geführt hat. Das soll uns bis auf Weiteres genügen … gleichwohl kann es selbstredend niemals Garantie gegen erfolgreiche Cracks geben.

Große Empfehlung: Hier ist ein äusserst fundierte Beitragsserie des Kuketz-Blog, in der sehr ausführlich und verständlich die Absicherung von WordPress-Seiten betrachtet wird: https://www.kuketz-blog.de/basisschutz-wordpress-absichern-teil1/

Wenn die Webseite doch mal gehackt wurde …

Egal wie aufwendig eine Webseite und ein Server abgesichert werden, es ist nur eine Frage der kriminellen Energie, bis auch das größte Bollwerk überwunden werden kann. Die meisten Webseiten bieten jedoch bei richtiger Absicherung im Rahmen des zu betreibenden Aufwands kein wirklich lohnendes Angriffsziel. Aber was tun, wenn es doch passiert?

Kein Grund zur Panik, wenn ein brauchbares und nicht kompromittiertes Backup zur Verfügung steht. Unser C•C•C•R•A•R•M – Vorschlag:

  • CUT! Webseite in den Wartungsmodus schalten bzw. anderweitig vor jeglichen Zugriffen vorübergehend stoppen.
    Dies kann am leichtesten über eine temporäre 301-Umleitung oder per serverseitigem Schutz (.htaccess) erreicht werden.
  • CHECK! Herausfinden, wie der Angreifer sich Zugang geschafft hat.
    Hier ist es gut, sich die Zugriffsprotokolle des Servers oder der verwendeten Sicherheitssoftware zu analysieren. In Zusammenhang mit den Zeitstempeln der Dateien und Verzeichnisse lassen sich hier mit geübtem Blick meist recht schnell die Schwachstellen ausmachen.
  • CLEAN! Schadcode finden und entfernen.
    Hierbei sind nicht nur verdächtige Dateien zu eliminieren, sondern auch fremder Schadcode innerhalb von Dateien sowie Fremdeinträge und Manipulationen in der Datenbank.
  • RESTORE! Letztes Backup vor dem Angriff wieder herstellen.
  • ACCOUNTS! Zugänge (Benutzername und Passwort) ändern für

    • FTP (SFTP)
    • Datenbank
    • WordPress Benutzer, auch die Benutzernamen und Login ändern
    • Datenbank-Präfix ändern
    • ggf. noch weitere Zugangsdaten, über die der Angreifer eventuell Kenntnis erlangt haben könnte
    • den SALT-Bereich in der Datei wp-config.php erneuern

     

  • RESTART! Das wiederhergestellte Backup ggf. mit den Aktualisierungen aufspielen und natürlich die gehackte Sicherheitslücke mit den technischen Neuerungen ebenso schließen. Und nicht vergessen, „den Vorhang wieder aufzumachen“, also die Webseite wieder sichtbar zu schalten und diese abgemeldet(!) auf Fehlerfreiheit und Aktualität zu überprüfen, auch an anderen Endgeräten.
  • MONITORING! Die Angriffe, die (erst recht nach erfolgtem Hack) stattfinden werden, protokollieren, observieren und bewerten und die Sicherheitsstrategie evtl. anpassen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Durch die weitere Nutzung der Seite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen