WP Security und der Befund „The file .htaccess does not exist in wp-admin/.

WP Security führt eine Sicherheits-Analyse des WordPress-Systems durch, in dem das Plugin installiert ist. Die Ausgabe des Scans zeigt bestehende Lücken und Einfallstore auf.

Schön: Der Anwender bzw. Betrachter der FrontEnd-Seite sieht nichts davon und laufzeit-kritisch ist es auch nicht. Also: Das Plugin und seine Ausgabe ist nur im Dashboard-Menü für Administratoren sichtbar und schluckt keine Rechenzeit, solange man den Scan nicht ausführt. Ein Scan dauert zumeist einige Sekunden – danach macht das Tool dann wieder nichts. So wie es sein soll.

Auf der Schattenseite: das Plugin wendet sich eher an Experten und erfahrene Server-Administratoren. Einfache Betreiber, die die WordPress-Dateien via FTP in einen Ordner geschoben haben – sich ansonsten mit dem Server aber nicht weiter beschäftigen, tun sich mit den gemeldeten Mängeln bzw. deren Behebung schwer.  Untern Strich handelt es also um ein Usability-Problem.

Es wäre es wahrlich nicht mehr wild gewesen, wenn die Autoren nach der Programmierung der ganzen Checks einige Tipps zum Output dazu geschrieben hätten. Beim Schreiben dieses Textes meldet die Google-Suche zur Eingabe des Suchtextes „wp security scan .htaccess“ gute 108.000 Ergebnisse. Ein schönes Beispiel für die Kosten fehlender Usability-Eigenschaften. Weil EIN jemand in einer Dokumentation oder einer kleinen Hilfe-Box nicht mehr beschreiben wollte, was sein Tool eigentlich besagt, haben nun 10.000de Anwender diese Frage gestellt und in Foren damit Kapazität von Unterstützern blockiert, Folge-Diskussionen ausgelöst etc.

WP Security - scan result with alert

WP Security – scan result with alert

Natürlich wollen wir hier nicht undankbar erscheinen. Schön, dass Leute sich die Arbeit machen und solche wertvollen Tool programmieren und sogar kostenlos zur Verfügung stellen – ohne jede Polemik. Ärgerlich ist aber schon, wenn nach Tagen oder Wochen dieser Arbeit hinterher 45 Minuten zur Beschreibung fehlen. So schön Open-Source-Software ist – dies ist ein berechtigtes gefundenes Fressen für die Zweifler. Deren Mantra – solches Software verursacht nur endlos Nacharbeit und Gefrickel– wird trotz allem Nutzen des Tools wieder einmal mehr völlig unnötig bestätigt.

Was bedeutet das?

Hinter .htaccess-Dateien steckt ein Konzept der Apache Webserver. Es handelt sich tatsächlich um Dateien mit eben diesem Namen. Dateien diesen Names steuern die Sichtbarkeit von Dateiinhalten in den Verzeichnissen, die Apache-Webserver nach außen sichtbar machen. Der Reihe nach:

  • Ein Rechner ist mit dem Internet verbunden.
  • Ein Webserver ist darauf installiert
  • Jemand gibt die Internet-Adresse dieses Rechners in einem Browser ein (natürlich ebenfalls mit korrekter Internet-Verbindung etc.)

Dann sieht diese Person auf ihrem Rechner entweder eine HTML-Startseite oder eine Auflistung des Verzeichnis-Inhalts, ähnlich wie in einem Explorer.

Das sind die Standardverhaltensweise von Apache:

  1. Wenn Inhalte in HTML, PHP da sind – insbesondere Dateien mit den Namen index.html oder index.php, dann liefere diese in standardisierter Form aus. Das liefert dem Aufrufer in den Browser dann z.B. die vom Surfen im Netz bekannten Inhalte.
  2. Wenn keine HTML- oder PHP-Inhalte da sind, dann liefere ein Directory Listing. Also: zeige die Dateien und Verzeichnisse an, die in dem Verzeichnis für Webinhalte hinterlegt sind.

Letzteres ist mittlerweile problematisch geworden. Angreifer können nun die Dateinahmen durchgehen und z.B. nach Fehlern und Lücken in der Rechte-Vergabe suchen. Auch das Wissen um bestimmte Code-Dateien ist heute gefährlich: Angreifer können darin ihre eigenen Schadcodes einbetten. Darum unterbindet man solche Auflistungen heute. Hier kommen nun .htaccess-Dateien ins Spiel.

Die meisten Anwender hätten einfache gerne etwas, dass die Analyse des Scan-Toos befriedigt. Einfach eine leere .htaccess-Datei in den angezeigten Ordner legen, kann – angesichts der Funktionaltität von .htaccess-Dateien – keine angemessene Lösung sein.

Was sollte eine .htaccess-Datei für Apache-Server nun enthalten?

Haftungsausschluß: Diese Hinweise sind nach bestem Wissen und Gewissen erstellt. Wenn sie diese Tipps befolgen oder anwenden, dann auf eigenes Risiko. Unter keinen Umständen kann ich jegliche Lücken auf Systemen hier behandeln oder vorhersehen. Es handelt sich hier nur um ganz allgemeine Angaben. Keine solche Einstellung kann zuverlässig verhindern, dass ihr System nicht dennoch damit zusammenhängende oder weitere Lücken aufweist. Beachten sie insbesondere: Bislang ist mir kein System bekannt, dass bei einem gezielten Angriff nicht doch irgendwann geöffnet, manipuliert oder missbraucht werden konnte. Alles was sie machen können ist lediglich die Hürden soweit zu erhöhen, dass unspezifische Angreifer nicht auch noch Standardlücken finden. Nicht zuletzt handelt es sich bei diesen Darstellungen um meine Meinung. Bekanntermaßen gibt es auch im IT-Bereich zu diesen Themen unterschiedliche Ansichten.

Ein einfacher Vorschlag umfasst etwa folgende Anweisungen:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php

[L]
# END WordPress

WP-Security-Scan without Alert

WP-Security-Scan without Alert

  • Diese Zeilen müssen also in einem Text-Editor (keine Textverarbeitung!) in eine Datei geschrieben werden.
  • Die Datei muss unter dem Namen .htaccess gespeichert werden
  • Die Datei .htaccess muss in den Ordner wp-admin unterhalb des Wurzelordners des betreffenden Blogs abgelegt werden.

Ein erneuter Scan sollte danach die betreffende Meldung in grün ohne Alarmierung ausgeben.

Was bedeuten diese Anweisungen?

RewriteEngine On

Aktiviert die Umsetzung von technischen Adressen in Alternativadressen. WordPress setzt URLs dynamisch zusammen. Die Webseiten, die Besucher sehen, existieren in dieser Form als HTML-Dateien nicht – sie werden nur für den jeweiligen Besucher aus Datensätzen per PHP-Anweisungen zusammengesteckt. Diese Anweisung aktiviert, dass interne Adressen wie www.server.de/post.php?2245 von außen unter anwendergerechteren Namen wie etwa www.server.de/urlaubsberichte erreichbar sind.

RewriteBase /

Teilt dem Server mit, dass die Anfrage über genau den aktuellen Pfad gekommen ist.  Die Anweisung kann in anderen Fällen genutzt werden, um Umleitungen z.B. von Unterverzeichnissen auf das Wurzelverzeichnis auschließlich zu erzeugen.

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

Prüft, ob das in der  Anfrage enthaltene Element existiert. Apache unterscheidet zwischen Files (f) und Directories (d), daher zwei Anweisungen. Existierende Dateien und Ordner sollen damit vom Rewrite ausgenommen werden.

RewriteRule . /index.php [L]

„Ziel“ der Rewrite-Prozedur.

Zusammengefasst: Wenn ein Request zu einer nicht vorhandenen Seite oder einem nicht vorhandene Ordner auftrittm, dann soll er behandelt werden, wie ein Aufruf zum Standardziel index.php (bzw. diesen untergeschoben kriegen).

Der Apache-Sever kann noch vieles mehr. Mit diesen Anweisungen läßt sich z.B. HotLinking auf eigene Bilder unterbinden, unerwünschter Traffic abhalten etc. Die gezeigten Anweisungen sind nur das denkbar Minimale bei vielen Apache-Installation, um den WP Security-Alarm abzustellen. Ein schöner Pool an Vorschlägen und Lösungen ist z.B. bei AskApache zu finden: http://www.askapache.com/htaccess/mod_rewrite-tips-and-tricks.html.