Eine der gängigsten Best Practices für die Sicherheit in diesen Tagen scheint darin zu bestehen , wp-config.phpein Verzeichnis höher als das Dokumentstammverzeichnis des vhost zu verschieben . Ich habe nie wirklich eine gute Erklärung dafür gefunden, aber ich gehe davon aus, dass es das Risiko eines böswilligen oder infizierten Skripts innerhalb der Webroot minimieren soll, wenn das Datenbankkennwort gelesen wird.

Sie müssen jedoch weiterhin WordPress darauf zugreifen lassen, sodass Sie open_basedirdas Verzeichnis oberhalb des Dokumentstamms erweitern müssen. Wird damit nicht nur der gesamte Zweck zunichte gemacht und möglicherweise auch Serverprotokolle, Sicherungen usw. Angreifern ausgesetzt?

Oder versucht die Technik nur, eine Situation zu verhindern, wp-config.phpin der jeder http://example.com/wp-config.php, der dies wünscht , im Klartext angezeigt wird , anstatt von der PHP-Engine analysiert zu werden? Dies scheint ein sehr seltenes Ereignis zu sein und würde die Nachteile des Offenlegens von Protokollen / Backups / usw. für HTTP-Anforderungen nicht aufwiegen.

Vielleicht ist es möglich, es in einigen Hosting-Setups aus dem Dokumentenstamm zu verschieben, ohne andere Dateien verfügbar zu machen, aber nicht in anderen Setups?

Fazit: Nach langem Hin und Her zu diesem Thema sind zwei Antworten aufgetaucht, die meines Erachtens als die maßgeblichen angesehen werden sollten. Aaron Adams macht einen guten Fall für das Verschieben von wp-config, und chrisguitarguymakes macht einen guten Fall dagegen . Dies sind die beiden Antworten, die Sie lesen sollten, wenn Sie neu im Thread sind und nicht das gesamte Thema lesen möchten. Die anderen Antworten sind entweder redundant oder ungenau.

Kurze Antwort: ja

Die Antwort auf diese Frage ist ein eindeutiges Ja und es ist völlig unverantwortlich , etwas anderes zu sagen .

Lange Antwort: ein reales Beispiel

Gestatten Sie mir, ein sehr reales Beispiel von meinem sehr realen Server zu liefern, bei dem das Verschieben wp-config.phpaußerhalb des Webstamms speziell das Erfassen seines Inhalts verhinderte .

Der Fehler:

Werfen Sie einen Blick auf diese Beschreibung eines Fehlers in Plesk (behoben in 11.0.9 MU # 27):

Plesk setzt die Weiterleitung von Subdomains zurück, nachdem das Abonnement mit dem Hosting-Plan synchronisiert wurde (117199)

Klingt harmlos, oder?

Nun, hier ist, was ich getan habe, um diesen Fehler auszulösen:

1. Richten Sie eine Subdomain ein, um zu einer anderen URL umzuleiten (z . B. site.staging.server.comzu site-staging.ssl.server.com).
2. Der Serviceplan des Abonnements wurde geändert (z. B. die PHP-Konfiguration).

Als ich dies getan habe, hat Plesk die Subdomain auf die Standardeinstellungen zurückgesetzt: Inhalte von werden bereitgestellt ~/httpdocs/, ohne dass Interpreter (z. B. PHP) aktiv sind.

Und ich habe es nicht bemerkt. Für Wochen.

Das Ergebnis:

• Mit wp-config.phpim Webroot /wp-config.phphätte eine Aufforderung die WordPress-Konfigurationsdatei heruntergeladen.
• Bei wp-config.phpaußerhalb des Webstamms eine Aufforderung zum /wp-config.phpHerunterladen einer völlig harmlosen Datei. Die echte wp-config.phpDatei konnte nicht heruntergeladen werden.

Daher ist es offensichtlich, dass das Verschieben wp-config.phpaußerhalb des Webstamms echte Sicherheitsvorteile in der realen Welt bietet .

So bewegen Sie sich wp-config.phpan einen beliebigen Ort auf Ihrem Server

WordPress sucht automatisch in einem Verzeichnis über Ihrer WordPress-Installation nach Ihrer wp-config.phpDatei. Wenn Sie diese also dort verschoben haben, sind Sie fertig!

Aber was ist, wenn Sie es woanders hingelegt haben? Einfach. Erstellen Sie eine neue wp-config.phpim WordPress-Verzeichnis mit dem folgenden Code:

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');

(Stellen Sie sicher, dass Sie den obigen Pfad in den tatsächlichen Pfad Ihrer verschobenen wp-config.phpDatei ändern .)

Wenn Sie auf ein Problem mit open_basedirstoßen, fügen Sie einfach den neuen Pfad zur open_basedirDirektive in Ihrer PHP-Konfiguration hinzu:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

Das ist es!

Argumente auseinandernehmen

Jedes Argument gegen das Verschieben wp-config.phpaußerhalb der Webwurzel hängt von falschen Annahmen ab.

Argument 1: Wenn PHP deaktiviert ist, sind sie bereits in

Die einzige Möglichkeit, wie jemand den Inhalt von [ wp-config.php] sieht, besteht darin, den PHP-Interpreter Ihres Servers zu umgehen. In diesem Fall haben Sie bereits Probleme: Er hat direkten Zugriff auf Ihren Server.

FALSE : Das oben beschriebene Szenario ist das Ergebnis einer Fehlkonfiguration und kein Eingriff.

Argument 2: Versehentliches Deaktivieren von PHP ist selten und daher unbedeutend

Wenn ein Angreifer genügend Zugriff hat, um den PHP-Handler zu ändern, sind Sie bereits geschraubt. Nach meiner Erfahrung sind versehentliche Änderungen sehr selten, und in diesem Fall wäre es einfach, das Kennwort zu ändern.

FALSE : Das oben beschriebene Szenario ist das Ergebnis eines Fehlers in einer allgemeinen Serversoftware, der sich auf eine allgemeine Serverkonfiguration auswirkt. Dies ist kaum "selten" (und außerdem bedeutet Sicherheit, sich über das seltene Szenario Gedanken zu machen).

WTF : Das Ändern des Passworts nach einem Eindringen hilft kaum, wenn während des Eindringens vertrauliche Informationen erfasst wurden. Glauben wir wirklich immer noch, dass WordPress nur für gelegentliches Bloggen verwendet wird und dass Angreifer nur an einer Verunstaltung interessiert sind? Sorgen wir uns darum, unseren Server zu schützen und nicht nur wiederherzustellen, nachdem jemand hereingekommen ist.

Argument 3: Den Zugang zu verweigern wp-config.phpist gut genug

Sie können den Zugriff auf die Datei über Ihre virtuelle Hostkonfiguration .htaccesseinschränken oder - den Zugriff von außen auf die Datei auf die gleiche Weise wie beim Verschieben außerhalb des Dokumentstamms einschränken.

FALSCH : Stellen Sie sich vor Ihrem Server Standardwert für einen virtuellen Host ist: keine PHP, keine .htaccess, allow from all(kaum ungewöhnlich in einer Produktionsumgebung). Wenn Ihre Konfiguration während eines Routinevorgangs auf irgendeine Weise zurückgesetzt wird , z. B. durch ein Panel-Update, wird der Standardzustand wiederhergestellt, und Sie werden freigelegt.

Wenn Ihr Sicherheitsmodell versagt, wenn die Einstellungen versehentlich auf die Standardeinstellungen zurückgesetzt werden, benötigen Sie mehr Sicherheit.

WTF : Warum würde jemand speziell weniger Sicherheitsebenen empfehlen? Teure Autos haben nicht nur Schlösser. Sie haben auch Alarme, Wegfahrsperren und GPS-Tracker. Wenn es sich lohnt, etwas zu schützen, machen Sie es richtig.

Argument 4: Unbefugter Zugriff wp-config.phpist keine große Sache

Die Datenbankinformationen sind wirklich die einzigen vertraulichen Inhalte in [ wp-config.php].

FALSE : Die Authentifizierungsschlüssel und Salt können für eine beliebige Anzahl potenzieller Hijacking-Angriffe verwendet werden.

WTF : Auch wenn Datenbankanmeldeinformationen das einzige sind wp-config.php, sollten Sie Angst davor haben, dass ein Angreifer sie in die Hände bekommt.

Argument 5: Durch das Verschieben wp-config.phpaußerhalb des Webstamms wird ein Server weniger sicher

Sie müssen WordPress weiterhin Zugriff auf [ wp-config.php] gewähren , sodass Sie open_basedirdas Verzeichnis über dem Dokumentstamm einschließen müssen.

FALSE : Angenommen, es wp-config.phpist in httpdocs/, verschieben Sie es einfach auf ../phpdocs/und legen Sie fest open_basedir, dass nur httpdocs/und eingeschlossen werden phpdocs/. Zum Beispiel:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

(Denken Sie daran, immer anzugeben /tmp/, oder Ihr Benutzerverzeichnis tmp/, falls Sie eines haben.)

Fazit: Konfigurationsdateien sollten immer immer immer außerhalb des Web - Root befindet

Wenn Ihnen die Sicherheit am Herzen liegt, werden Sie wp-config.phpaußerhalb Ihres Webstamms verschoben .

Das Größte ist, dass es wp-config.phpvertrauliche Informationen enthält: Ihren Datenbank-Benutzernamen / Passwort usw.

Also die Idee: Verschieben Sie es außerhalb des Dokumentenstamms, und Sie müssen sich um nichts kümmern. Ein Angreifer kann niemals von einer externen Quelle auf diese Datei zugreifen.

Hier ist jedoch der Haken: Druckt wp-config.phpnie etwas auf den Bildschirm. Es werden nur verschiedene Konstanten definiert, die in Ihrer WP-Installation verwendet werden. Der einzige Weg, wie jemand den Inhalt dieser Datei sehen kann, ist, wenn er den PHP-Interpreter Ihres Servers umgeht - er lässt die .phpDatei als reinen Text rendern. In diesem Fall sind Sie bereits in Schwierigkeiten: Sie haben direkten Zugriff auf Ihren Server (und möglicherweise Root-Berechtigungen) und können tun, was sie möchten.

Ich gehe vor und sage, dass es wp-configaus Sicherheitsgründen keinen Vorteil hat, außerhalb des Dokumentenstamms zu wechseln - aus den oben genannten Gründen und aus den folgenden Gründen:

1. Sie können den Zugriff auf die Datei über Ihre virtuelle Hostkonfiguration oder .htaccess einschränken - und so den Zugriff von außen auf die Datei auf die gleiche Weise wie beim Verschieben außerhalb des Dokumentstamms
2. Sie können sicherstellen, dass die Dateiberechtigungen streng sind wp-config, um zu verhindern, dass Benutzer ohne ausreichende Berechtigungen die Datei lesen, auch wenn sie über SSH (eingeschränkten) Zugriff auf Ihren Server erhalten.
3. Ihre vertraulichen Informationen, Datenbankeinstellungen, werden nur auf einer einzelnen Site verwendet. Selbst wenn ein Angreifer auf diese Informationen zugreifen würde, wäre die einzige betroffene Site die WordPress-Installation, zu der die wp-config.phpDatei gehört. Noch wichtiger ist, dass dieser Datenbankbenutzer nur Berechtigungen zum Lesen und Schreiben in der Datenbank dieser WP-Installation hat und nichts anderes - keinen Zugriff, um anderen Benutzern Berechtigungen zu erteilen. Mit anderen Worten, wenn ein Angreifer Zugriff auf Ihre Datenbank erhält, müssen Sie lediglich eine Sicherungskopie wiederherstellen (siehe Punkt 4) und den Datenbankbenutzer ändern
4. Sie sichern oft. Oftmals ein relativer Begriff: Wenn Sie jeden Tag 20 Artikel veröffentlichen, sollten Sie jeden Tag oder alle paar Tage eine Sicherungskopie erstellen. Wenn Sie einmal in der Woche posten, ist eine wöchentliche Sicherung wahrscheinlich ausreichend.
5. Sie haben Ihre Site unter Versionskontrolle ( so ), was bedeutet, dass Sie selbst dann, wenn ein Angreifer Zugriff hat, Codeänderungen leicht erkennen und rückgängig machen können. Wenn ein Angreifer Zugriff auf hat wp-config, hat er wahrscheinlich mit etwas anderem rumgespielt.
6. Die Datenbankinformationen sind wirklich die einzigen vertraulichen Daten wp-config, und da Sie vorsichtig damit sind (siehe Punkt 3 und 4), ist dies keine große Sache. Salze und dergleichen können jederzeit geändert werden. Das Einzige, was passiert, ist, dass die Cookies der angemeldeten Benutzer ungültig werden.

Für mich wp-configriecht das Herausziehen aus der Dokumentenwurzel nach Sicherheit durch Unbekanntheit - was in hohem Maße ein Strohmann ist.

Ich denke, Max ist eine sachkundige Antwort, und das ist eine Seite der Geschichte. Der WordPress-Codex hat weitere Ratschläge :

Stellen Sie außerdem sicher, dass nur Sie (und der Webserver) diese Datei lesen können (dies bedeutet im Allgemeinen eine 400- oder 440-Berechtigung).

Wenn Sie einen Server mit .htaccess verwenden, können Sie dies in diese Datei (ganz oben) einfügen, um den Zugriff auf alle zu verweigern, die danach surfen:

<files wp-config.php>
order allow,deny
deny from all
</files>

Beachten Sie, dass die Einstellung der 400- oder 440-Berechtigung in der Datei wp-config.php möglicherweise verhindert, dass Plug-ins darauf schreiben oder sie ändern. Ein echter Fall wäre beispielsweise, Plugins zwischenzuspeichern (W3 Total Cache, WP Super Cache usw.). In diesem Fall würde ich 600 wählen (die Standardberechtigung für Dateien im /home/userVerzeichnis).

Jemand hat uns gebeten, herein zu scheinen, und ich werde hier antworten.

Ja, das Isolieren Ihrer wp-config.php-Datei aus dem Stammverzeichnis Ihrer Website bietet Sicherheitsvorteile.

1- Wenn Ihr PHP-Handler kaputt geht oder auf irgendeine Weise modifiziert wird, werden Ihre DB-Informationen nicht angezeigt. Und ja, ich habe dies einige Male auf gemeinsam genutzten Hosts während der Serveraktualisierungen gesehen. Ja, die Website wird in diesem Zeitraum beschädigt, aber Ihre Passwörter bleiben erhalten.

2- Best Practices empfehlen immer, Konfigurationsdateien von Datendateien zu isolieren. Ja, das ist mit WordPress (oder einer anderen Web-App) schwer zu machen, aber es nach oben zu verschieben, ist etwas isolierend.

3- Denken Sie an die PHP-CGI-Sicherheitsanfälligkeit, bei der jeder das? -S an eine Datei übergeben und den Quellcode anzeigen kann. http://www.kb.cert.org/vuls/id/520827

Am Ende sind dies kleine Details, aber sie tragen dazu bei, das Risiko zu minimieren. Insbesondere, wenn Sie sich in einer gemeinsam genutzten Umgebung befinden, in der jeder auf Ihre Datenbank zugreifen kann (alles, was er benötigt, ist ein Benutzer / Pass).

Aber lassen Sie sich nicht von kleinen Ablenkungen (vorzeitigen Optimierungen) ablenken, die wirklich notwendig sind, um eine Website richtig abzusichern:

1- Halten Sie es immer aktuell

2- Verwenden Sie sichere Passwörter

3- Beschränken Sie den Zugriff (über Berechtigungen). Wir haben einen Beitrag dazu hier:

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

Vielen Dank,

Definitiv Ja.

Wenn Sie die Datei wp-config.php aus dem öffentlichen Verzeichnis verschieben, schützen Sie sie vor dem Lesen mit dem Browser, wenn der PHP-Handler böswillig (oder versehentlich!) Geändert wird.

Das Lesen Ihres DB-Login / Passworts ist möglich, wenn der Server durch einen Fehler des lahmen Administrators kaum infiziert ist. Stellen Sie dem Administrator eine Geldstrafe in Rechnung und sichern Sie sich einen gepflegten und zuverlässigeren Server-Host. Obwohl das teurer sein kann.

Ich möchte nur klarstellen, dass das Verschieben der Datei wp_config.php nicht unbedingt bedeutet, dass Sie sie nur in das übergeordnete Verzeichnis verschieben müssen. Angenommen, Sie haben eine Struktur wie / root / html, wobei html die WP-Installation und Ihren gesamten HTML-Inhalt enthält. Anstatt wp_config.php nach / root zu verschieben, können Sie es nach / root / secure ... verschieben, das sich sowohl außerhalb des HTML-Verzeichnisses als auch nicht im Server-Stammverzeichnis befindet. Natürlich müssten Sie sicherstellen, dass PHP auch in diesem sicheren Ordner ausgeführt werden kann.

Da WP nicht so konfiguriert werden kann, dass es in einem gleichrangigen Ordner wie / root / secure nach wp_config.php sucht, müssen Sie einen zusätzlichen Schritt ausführen. Ich habe die Datei wp_config.php in / root / html belassen und die sensiblen Teile (Datenbankanmeldung, Salt, Tabellenpräfix) herausgeschnitten und in eine separate Datei namens config.php verschoben. Dann fügen Sie den PHP- includeBefehl wie folgt zu Ihrer wp_config.php hinzu:include('/home/content/path/to/root/secure/config.php');

Dies ist im Wesentlichen das, was ich in meinem Setup getan habe. Jetzt, basierend auf der obigen Diskussion, prüfe ich immer noch, ob es notwendig oder sogar eine gute Idee ist. Aber ich wollte nur hinzufügen, dass die obige Konfiguration möglich ist. Es macht Ihre Sicherungen und andere Stammdateien nicht verfügbar. Solange der sichere Ordner nicht mit einer eigenen öffentlichen URL eingerichtet ist, kann er nicht durchsucht werden.

Darüber hinaus können Sie den Zugriff auf den sicheren Ordner einschränken, indem Sie dort eine .htaccess-Datei erstellen mit:

order deny,allow
deny from all
allow from 127.0.0.1

Es gibt viele schlecht geschriebene Themes und Plugins, die es Atatckern ermöglichen, Code einzufügen (denken Sie an die Sicherheitslücke bei Timthumb). Wenn ich ein Angreifer wäre, warum sollte ich dann nach der wp-config.php suchen? Füge einfach diesen Code ein:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Sie können versuchen, Ihre wp-config.php zu verstecken. Solange WordPress alle vertraulichen Informationen global zugänglich macht, hat es keinen Vorteil, die Datei wp-config.php auszublenden.

Der schlechte Teil in wp-config.php ist nicht, dass es vertrauliche Daten enthält. Der schlechte Teil ist, die sensiblen Daten als global zugreifbare Konstante zu definieren.

Aktualisieren

Ich möchte die Probleme mit define()und warum es eine schlechte Idee ist, sensible Daten als globale Konstante zu definieren , klären .

Es gibt viele Möglichkeiten, eine Website anzugreifen. Das Einfügen von Skripten ist nur eine Möglichkeit, eine Website anzugreifen.

Angenommen, der Server weist eine Sicherheitsanfälligkeit auf, durch die ein Angreifer auf einen Speicherauszug zugreifen kann. Der Angreifer findet im Speicher alle Werte aller Variablen. Wenn Sie eine global zugreifbare Konstante definieren, muss diese im Speicher bleiben, bis das Skript beendet wird. Wenn Sie eine Variable anstelle einer Konstante erstellen, besteht eine gute Chance, dass der Garbage Collector den Speicher überschreibt (oder freigibt), nachdem die Variable nicht mehr benötigt wird.

Eine bessere Möglichkeit, sensible Daten zu schützen, besteht darin, sie unmittelbar nach ihrer Verwendung zu löschen:

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

Nach Verwendung der sensiblen Daten nullwerden die Daten im Speicher durch die Zuweisung von überschrieben. Ein Angreifer muss den Speicherauszug genau in dem Moment erhalten, in dem er $db_condie sensiblen Daten enthält. Und das ist im obigen Beispiel eine sehr kurze Zeit (wenn die Klasse Database_Handler keine Kopie davon speichert).

Abgesehen von den Sicherheitsvorteilen können Sie damit auch Ihre WordPress-Instanz unter Versionskontrolle halten und gleichzeitig die wichtigsten WordPress-Dateien als Submodul / extern speichern. So hat Mark Jaquith sein WordPress-Skeleton-Projekt eingerichtet. Weitere Informationen finden Sie unter https://github.com/markjaquith/WordPress-Skeleton#assumptions .