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


135

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.


Es ist wirklich nicht notwendig, Ihre Antwortauswahl zu treffen und alle anderen Antworten innerhalb Ihrer Frage abzulehnen. Wie Sie weiter unten sehen können, dient das Stackexchange-Abstimmungssystem dazu, die für die Menschen sinnvollen Antworten abzustimmen, während die Fragesteller den "Accepted Answer" -Mechanismus und Ihre eigenen Up / Down-Abstimmungen verwenden sollten.
Kzqai

6
Ich mache das nicht für 99% der Fragen, die ich gestellt habe, aber ich fand es in diesem speziellen Fall angemessen. Es gibt 8 Antworten auf die Frage, von denen einige ziemlich lang / komplex sind und einige trotz unzutreffender Informationen oder fehlender Hinzufügung zu der Konversation viele positive Stimmen haben. Ich halte es für hilfreich, den Thread zum ersten Mal zu lesen, wenn Sie eine halb-autoritative Schlussfolgerung ziehen. Wie immer können sich die Leser frei entscheiden; Ich biete nur meine Meinung als OP an.
Ian Dunn

1
@ Kzqai: Das "Stackexchange Voting System" ist ein demokratischer Prozess, und die Teilnehmer sind häufig 1) unklar, was das OP tatsächlich fragt oder zu lösen versucht, und 2) nicht sicher, ob eine bestimmte Antwort gültig ist. Nachdem die Antworten eingegangen sind und die Stimmen abgegeben wurden, ist es mehr als hilfreich , dass das OP die Antworten klärt, die Unterstützung geleistet haben. Immerhin ist das OP das einzige, das es weiß, und ich wünschte, mehr OPs würden es tun. Ja, die Leute "stimmen über die Antworten ab, die für die Leute Sinn machen", aber lassen Sie das OP das letzte Wort darüber haben, was für ihn Sinn macht.
Mac

Antworten:


127

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 .


1
Wenn Sie einen Fehler in Apache, Linux oder dem Gehirn des Administrators haben, sind Sie auf jeden Fall ein Toast. In Ihrem Szenario können Sie nicht erklären, warum es wahrscheinlicher ist, dass eine Fehlkonfiguration im Stammverzeichnis der Website auftritt, als an einer anderen Stelle auf dem Server. Ein falsch konfigurierter Apache kann wahrscheinlich so einfach auf /../config.php zugreifen wie /config.php
Mark Kaplun

1
Sie sind auf keinen Fall "Toast". Es ist sehr wahrscheinlich und sogar nachweisbar , dass ein Fehler dazu führen würde, dass das Web-Stammverzeichnis auf den Standard zurückgesetzt wird. In diesem Fall sind Sie kein "Toast" - Sie sind wp-config.phpweiterhin sicher. Und es ist äußerst unwahrscheinlich - so sehr, dass dies im Wesentlichen unmöglich ist -, dass ein Fehler dazu führen würde, dass der Webstamm willkürlich auf das genaue Verzeichnis zurückgesetzt wird, in das Sie ihn gestellt haben wp-config.php.
Aaron Adams

1
@IanDunn Eigentlich ist es einfach, wp-config.phpan einen beliebigen Ort zu ziehen . Ich habe meiner Antwort eine Wegbeschreibung hinzugefügt. Es muss lediglich ein Dummy wp-config.phpim WordPress-Verzeichnis erstellt werden, der auf den Speicherort des realen verweist.
Aaron Adams

3
Diese Antwort ist genau richtig. Mein Webhosting-Unternehmen hatte einen Laufwerksarray-Fehler. Letztendlich haben sie das System TEILWEISE wiederhergestellt. Es hat sich herausgestellt, dass sie eine Reihe von cPanel / WHM-Skripten verwendet haben, um httpd.conf-Dateien neu zu erstellen, die dies nicht richtig gemacht haben. Glücklicherweise hatte ich wp-config.php bereits außerhalb des doc-Stammverzeichnisses, aber wenn ich es nicht getan hätte, wäre der Inhalt zum Mitnehmen da. Ja, selten, aber wie bereits erwähnt, sind die seltenen Fälle das, worüber Sie sich Sorgen machen müssen. Es ist auch eine schlechte Entschuldigung für die WENIGER Sicherheit, zu behaupten, dass "einfache Leute verloren wären".
Lance Cleveland

1
Das ist ein guter Punkt, Aaron. Ich bin immer noch ein bisschen skeptisch wegen der Gründe, die ich in diesem und anderen Kommentarthreads erwähnt habe, aber Sie haben mich überzeugt, dass es mehr Verdienst hat, als ich ursprünglich gedacht habe. Zumindest, wenn es richtig gemacht wird, glaube ich nicht, dass es irgendetwas verletzen wird. Ich habe immer noch ein Problem mit der Tatsache, dass die meisten Leute, die es bewerben, die Gründe dafür nicht zu verstehen scheinen und die Art und Weise, wie sie es lehren, häufig dazu führt, dass das Verzeichnis über httpdocs angezeigt wird, aber Sie haben dazu beigetragen, diese Probleme in zu beheben Ihre Antwort.
Ian Dunn

40

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.


2
Ja, das ist so ziemlich das, woran ich gedacht habe. Ich bin froh zu wissen, dass ich nicht der einzige bin :) Ich möchte die Frage für ein oder zwei weitere Tage offen lassen, nur für den Fall, dass jemand ein überzeugendes Gegenargument hat, aber bisher scheint dies die richtige Antwort zu sein mich.
Ian Dunn

3
Kleinere Korrekturen: Das Verschieben der Datei wp-config.php aus dem Stammverzeichnis des Dokuments bietet keinen Sicherheitsvorteil . Es gibt andere Vorteile, die nicht sicherheitsrelevant sind und nur für ungewöhnliche Setups gelten.
Otto

4
Nur um einen möglichen Mythos zu entlarven - ist es nicht möglich, dass serverseitig etwas schief geht - in welchem ​​Fall wird PHP-Code auf den Bildschirm gedruckt?
Stephen Harris

3
@IanDunn Aber die besten Antworten befürworten, dass Sie es aus dieser Hierarchie heraus in eine separate Hierarchie verschieben, die Ihre Bedenken in Bezug auf Protokolle usw. berücksichtigt. Diese Antwort beantwortet Ihren Fragentitel nicht Andere Sicherheitsmaßnahmen sind von Vorteil und sollen Sie beruhigen, sich keine Sorgen um die Sicherheit zu machen. Jeder denkt, dass sein Haus sicher ist, bis er eingebrochen wird. Danach machen sie einen besseren Job. Manche Leute werden nie eingebrochen, obwohl ihre Sicherheit niedrig ist, aber es bedeutet nicht, dass es ein guter Rat ist, eine niedrigere Sicherheit zu haben.
AndrewC

4
Das sind gute Punkte, aber mein größtes Problem dabei ist, dass es sich um Abhilfeargumente und nicht um vorbeugende Argumente handelt. Die meisten davon sprechen davon, dass es keine große Sache ist, weil A) Sie annehmen, dass jemand den Datenbankbenutzer korrekt behandelt hat und B) Sie Backups haben. Was passiert, wenn Sie so etwas wie Woocommerce verwenden oder vertrauliche Informationen in Ihrer Datenbank speichern? Dann bist du fertig.
Goldentoa11

25

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).


5
Max ist die Antwort. +1 für ihn. Ich versuche nur, es zu erweitern.
its_me

1
Aahan Krish, du hast den Volltreffer geschafft. Danke für den Zusatz.
Max Yudin

Wenn Sie also htaccess verwenden, um HTTP-Anforderungen an die Datei wp-config.php abzulehnen, wird dann nicht dasselbe Ergebnis erzielt wie beim Verschieben außerhalb des Dokumentstamms, ohne jedoch Protokolle / Sicherungen / usw. offen zu legen?
Ian Dunn

4
@IanDunn Hängt davon ab, was der Dokumentenstamm ist - (1) Wenn WordPress in einem Verzeichnis in gehostet wird public_html, wp-config.phpbedeutet das Verschieben außerhalb des Verzeichnisses, dass es sich in einem public_htmlVerzeichnis befindet. In diesem Fall müssen Sie die htaccess-Regeln verwenden, um HTTP-Anforderungen an die Datei wp-config.php abzulehnen. (2) Wenn WordPress direkt unter dem public_htmlVerzeichnis installiert ist , eine Ebene höher => werden Sie es in das /home/userVerzeichnis verschieben. In diesem Fall sind Sie ziemlich sicher, da sich die Datei außerhalb des Dokumentstamms befindet. Sie können die Berechtigungen der Datei weiterhin auf 600 (oder noch strenger auf 440 oder 400) festlegen.
its_me

@ IanDunn Wie gesagt, das ist mein Grundverständnis und ich bin kein Sicherheitsexperte. :)
its_me

17

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,


Hey Leute, danke für deine Gedanken. Ich denke, wir treffen bereits auf die meisten dieser Punkte in den anderen Antworten und deren Kommentaren. 1) Ja, das ist möglich, aber selten; 2) Ja, das hat Vorteile, aber sie sind minimal; 3) Ja, das ist möglich, aber es ist unwahrscheinlich, dass diese Art von Sicherheitslücke erneut auftritt. Ein Schutz dagegen ähnelt dem Spielen von Whac-a-Mole oder dem Ausziehen der Schuhe an Flughäfen, weil irgendein Esel eine Bombe in seiner versteckt hat einmal beschuhen. Es ist reaktionär und es ist unwahrscheinlich, dass es künftige Vorteile bringt.
Ian Dunn

In den verschiedenen Diskussionen wurde die Frage von "Gibt es irgendwelche Vorteile?" zu "Ok, es gibt einige Vorteile, aber überwiegen sie die Risiken?" Das Hauptrisiko, auf das ich mich beziehe, ist die Tatsache, dass Sie den Bereich openbase_dir erweitern müssen, damit PHP auf Skripte außerhalb des Webstamms zugreifen kann. Viele Hosting-Setups - einschließlich derjenigen, die häufig Plesk verwenden - speichern Protokolle, Backups, private FTP-Bereiche, die vom Webstamm usw. im Verzeichnis über dem Webstamm isoliert werden sollen. Daher kann es eine ernsthafte Sicherheitsanfälligkeit sein, PHP Zugriff auf dieses Verzeichnis zu gewähren.
Ian Dunn

15

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.


4
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. Glauben Sie angesichts dieser Umstände immer noch, dass es sich aufgrund des erweiterten open_basedirUmfangs lohnt, Protokolle / Backups / usw. bereitzustellen?
Ian Dunn

1
Ich hatte noch nie -rwxZugang zu höheren Verzeichnissen, als public_htmlmir bekannt war open_basedir. Meine Protokolle befinden sich in einem separaten Verzeichnis. Dies gilt auch für Sicherungen. Ich denke, das haben alle Shared Hosts.
Max Yudin

Wirte variieren stark; Es gibt keine Standardverzeichnisstruktur. Plesk (eines der beliebtesten Kontrollfelder für gemeinsam genutzte Hosts) legt Protokolle in /var/www/vhosts/example.com/statistics/logs ab, und das Stammverzeichnis des Dokuments lautet /var/www/vhosts/example.com/httpdocs. Wenn Sie wp-config.php nach /var/www/vhosts/example.com/wp-config.php verschieben, müssen Sie den Skripten Zugriff auf das gesamte Verzeichnis example.com gewähren.
Ian Dunn

Wo werden aus Neugier Ihre Protokolle und Backups gespeichert, wenn nicht im Verzeichnis der Domain? Werden sie über ein Bedienfeld oder etwas zugegriffen?
Ian Dunn

1
Ja, über ein Bedienfeld.
Max Yudin

8

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

Hey Michael, danke, dass du das geteilt hast. Haben Sie es in einer realen Umgebung versucht, um zu überprüfen, ob es funktioniert? Ich denke , die open_basedirRichtlinie einen ganzen nimmt Baum , so zuzugreifen , um /root/secureaus /root/html, dann würden Sie setzen müssen open_basedirzu /root.
Ian Dunn

Um Ihre Idee zum Laufen zu bringen, müssten Sie vermutlich die Verzeichnisstruktur einrichten /root/httpdocs/config/accessible, in httpdocsder Protokolle, Sicherungen usw. gespeichert sind. confighält wp-config.phpund accessiblehält WordPress und alle Inhalte. Sie müssten die vhost-Konfiguration usw. ändern, um den Dokumentenstamm neu zuzuordnen accessible. Ich sehe jedoch keinen Vorteil darin, nur HTTP-Anfragen an wp-config im Standard-Setup abzulehnen.
Ian Dunn

1
Laut php.net/manual/en/ini.core.php#ini.open-basedir : " Trennen Sie unter Windows die Verzeichnisse mit einem Semikolon. Trennen Sie auf allen anderen Systemen die Verzeichnisse mit einem Doppelpunkt. Als Apache-Modul open_basedir-Pfade von übergeordneten Verzeichnissen werden jetzt automatisch vererbt. " Sie können also mehrere Verzeichnisse festlegen, ohne dass diese in einem einzigen Baum gespeichert sein müssen.
Michael

Ich habe das gerade ausprobiert und es sieht so aus, als hättest du recht. Ich bin mir jedoch immer noch nicht sicher, welchen Sicherheitsvorteil dies hat, wenn der Zugriff auf die Datei über Apache verweigert wird.
Ian Dunn

@ IanDunn gut angesprochen in Aaron Adams Antwort
AndrewC

4

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).


Diese Antwort geht nicht direkt auf die Frage ein. Jeder Plug-in-Autor kann einen Tag mit WordPress verbringen, wenn er Sie davon überzeugt, seinen Code zu installieren und böswillige Absichten zu haben. Dies ist nicht anders als die freiwillige Installation eines Virus auf Ihrem System. Dieses Argument, wp-config.php nicht zu verschieben, ist sinnlos. Dies ist so, als würde man sagen, dass das absichtliche Installieren einer Autobombe in Ihrem Auto das Einstellen des Autoalarms unbrauchbar macht. Technisch gesehen aber WTF?!?
Lance Cleveland

2
Nein, es ist nicht sinnlos. Die Frage ist: Kann ich das Datenbankkonto schützen, indem ich die Datei wp-config.php verstecke? Und die Antwort ist eindeutig: Nein. Es ist das Gleiche, als würden Sie fragen: Kann ich mein Auto mit einer Alarmanlage vor Autobomben schützen? Es gibt keinen anderen Vorteil, wenn Sie Ihre wp-config verstecken, als den Datenbankzugriff oder den FTP-Zugriff zu schützen. Beide sind im globalen Geltungsbereich. Ich bin mir sicher, dass es für Angreifer weitere Möglichkeiten gibt, auf globale Variablen zuzugreifen, ohne Code einzufügen.
Ralf912

Ich sehe in der ursprünglichen Frage nicht "Kann ich das Datenbankkonto schützen, indem ich die Datei wp-config.php verstecke?". Die ursprüngliche Frage war "Ist es sinnvoll, die wp-config.php zu verschieben?". Die Antwort ist absolut ja, IMO. Es ist wie zu fragen, ob Sie Ihre Haustür abschließen sollten, wenn Sie ausgehen. Das Sprichwort "Jemand kann leicht ein Fenster einbrechen und trotzdem einsteigen, also warum sich die Mühe machen" beantwortet den grundlegenden Punkt der Frage nicht. IMO lautete die Frage: "Lohnt sich der zusätzliche Aufwand, um die Datei wp-config.php zu verschieben? JEDER Vorteil, der damit verbunden ist?". Ja. Zumindest hält es die faulen Hacker fern.
Lance Cleveland

2
Eine der gängigsten Best Practices für die Sicherheit ... Sie haben einen sehr (sehr, sehr) wichtigen Punkt übersehen: Woran interessiert sich ein Angreifer? Und es ist nicht wie du deine wp-config.php gestylt hast. Ein Angreifer ist an den Werten interessiert, die Sie in Ihrer wp-config definiert haben. Greifen Sie zu Ihrem Beispiel mit der Haustür: Das Verstecken Ihrer WP-Konfiguration ist dasselbe, als würden Sie Ihre Haustür abschließen, aber all Ihr Gold ungeschützt im Garten aufbewahren. Alle in der wp-config definierten Werte sind global definiert. Sie sind also alle außerhalb von wp-config zugänglich. Auch wenn Sie Ihre wp-config verstecken, sind die Werte immer noch vorhanden.
Ralf912

1
Ich denke, dass diejenigen, die sich für eine Verschiebung aussprechen, versuchen, sich vor Szenarien zu schützen, in denen wp-config.php über eine HTTP-Anfrage im Klartext angezeigt werden könnte, anstatt Szenarien, in denen es anderen PHP-Codes ausgesetzt sein könnte, die auf dem Host ausgeführt werden.
Ian Dunn

-1

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 .


8
Er hat es im Dokumentenstamm eingerichtet, nicht außerhalb davon, daher ist es für diese Frage nicht relevant. Die Technik, zu der die Frage gestellt wurde, gibt an, dass Sie wp-config.phpein Verzeichnis über dem Dokumentstamm des vhost und nicht nur ein Verzeichnis über dem WordPress-Installationsordner verschieben. Der springende Punkt ist, es außerhalb des Ordners abzurufen, der von HTTP-Anforderungen gelesen werden kann.
Ian Dunn
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.