it-swarm.com.de

Ist es wirklich vorteilhaft, wp-config außerhalb des Webstamms zu verschieben?

Eine der gängigsten Best Practices für die Sicherheit in diesen Tagen ist Verschieben von wp-config.php um ein Verzeichnis höher als das Dokumentstammverzeichnis des vhost . Ich habe nie wirklich eine gute Erklärung dafür gefunden, aber ich gehe davon aus, dass dies das Risiko eines böswilligen oder infizierten Skripts in der Webroot minimieren soll, das das Datenbankkennwort liest.

Sie müssen jedoch weiterhin WordPress darauf zugreifen lassen, sodass Sie open_basedir erweitern müssen, um das Verzeichnis oberhalb des Dokumentstamms einzuschließen. 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, in der wp-config.php als Klartext für jeden angezeigt wird, der http://example.com/wp-config.php anfordert, anstatt von der PHP -Engine analysiert zu werden? Dies scheint ein sehr seltenes Ereignis zu sein und würde die Nachteile der Bereitstellung von Protokollen/Backups/etc 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 einem langen Hin und Her zu diesem Thema sind zwei Antworten aufgetaucht, die meines Erachtens als die maßgeblichen zu betrachten sind. Aaron Adams macht ein gutes Argument für das Verschieben von wp-config, und chrisguitarguy macht ein gutes Argument 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.

131
Ian Dunn

Das Größte ist, dass der wp-config.php vertrauliche Informationen enthält: Ihren Datenbank-Benutzernamen/Ihr Datenbank-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: wp-config.php druckt nie etwas auf den Bildschirm. Es werden nur verschiedene Konstanten definiert, die in Ihrer WP -Installation verwendet werden. Die einzige Möglichkeit, mit der jemand den Inhalt dieser Datei sehen kann, besteht darin, den PHP -Interpreter Ihres Servers zu umgehen. Sie erhalten .php -Dateien, die nur als einfacher Text wiedergegeben werden. 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 werde fortfahren und sagen: Aus Sicherheitsgründen hat es keinen Vorteil, wp-config aus dem Dokumentenstamm zu verschieben. - Aus den oben genannten Gründen und aus den folgenden Gründen:

  1. Sie können den Zugriff auf die Datei über Ihre virtuelle Host-Konfiguration oder .htaccess einschränken - und somit den Zugriff von außen auf die Datei auf dieselbe Weise wie beim Verschieben außerhalb des Dokumentstamms
  2. Sie können sicherstellen, dass die Dateiberechtigungen für wp-config streng sind, 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.php-Datei 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 Sicherung wiederherstellen (siehe Punkt 4) und den Datenbankbenutzer ändern
  4. Sie sichern häufig. 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 ( wie diese ), dh selbst wenn ein Angreifer Zugriff hat, können Sie Codeänderungen leicht erkennen und rückgängig machen. Wenn ein Angreifer Zugriff auf wp-config hat, hat er wahrscheinlich etwas anderes durcheinander gebracht.
  6. Die Datenbankinformationen sind wirklich die einzigen vertraulichen Informationen in 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 gewechselt werden. Das Einzige, was passiert, ist, dass die Cookies der angemeldeten Benutzer ungültig werden.

wp-config aus der Dokumentenwurzel zu entfernen, stinkt nach Sicherheit durch Unbekanntheit - was in hohem Maße ein Strohmann ist.

40
chrisguitarguy

Ich denke, Max ist eine sachkundige Antwort, und das ist eine Seite der Geschichte. Der WordPress Codex hat mehr 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 Verzeichnis /home/user).

25
its_me

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 beschädigt oder auf irgendeine Weise geändert 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 Site 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).

Lassen Sie sich jedoch nicht durch kleine Ablenkungen (vorzeitige Optimierungen) davon ablenken, was wirklich notwendig ist, um eine Website ordnungsgemäß 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,

17
Sucuri

Definitiv Ja.

Wenn Sie wp-config.php außerhalb des öffentlichen Verzeichnisses verschieben, schützen Sie es 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.

15
Max Yudin

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 für die Suche nach wp_config.php in einem gleichrangigen Ordner wie/root/secure konfiguriert werden kann, 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 Befehl PHP include 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
8
Michael

Es gibt viele schlecht geschriebene Themes und Plugins, mit denen Atacker Code einschleusen können (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ügen Sie 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.

Update

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

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 sofort 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 werden die Daten im Speicher durch die Zuweisung zu null überschrieben. Ein Angreifer muss den Speicherauszug nur in dem Moment abrufen, in dem $db_con die vertraulichen Daten enthält. Und das ist im obigen Beispiel eine sehr kurze Zeit (wenn die Klasse Database_Handler keine Kopie davon speichert).

4
Ralf912