Krótka odpowiedź: tak
Odpowiedź na to pytanie jest jednoznaczna , a powiedzenie inaczej jest całkowicie nieodpowiedzialne .
Długa odpowiedź: przykład z prawdziwego świata
Pozwólcie, że podam bardzo prawdziwy przykład z mojego bardzo prawdziwego serwera, gdzie przeniesienie się wp-config.phppoza katalog główny sieci web szczególnie uniemożliwiło przechwycenie jego zawartości .
Błąd:
Spójrz na ten opis błędu w Plesku (naprawiony w 11.0.9 MU # 27):
Plesk resetuje przekazywanie subdomen po zsynchronizowaniu subskrypcji z planem hostingowym (117199)
Brzmi nieszkodliwie, prawda?
Oto co zrobiłem, aby uruchomić ten błąd:
- Skonfiguruj poddomenę, aby przekierowywać na inny adres URL (np.
site.staging.server.comDo site-staging.ssl.server.com).
- Zmieniono abonament usługi (np. Konfigurację PHP).
Kiedy to zrobiłem, Plesk zresetował subdomenę do wartości domyślnych: wyświetlanie zawartości ~/httpdocs/bez aktywnych tłumaczy (np. PHP).
I nie zauważyłem. Przez tygodnie.
Wynik:
- W
wp-config.phpkatalogu głównym żądanie do /wp-config.phppobrania pliku konfiguracyjnego WordPress.
- Z
wp-config.phpzewnątrz korzenia internetowej, wniosek do /wp-config.phppobrania całkowicie nieszkodliwy plik. wp-config.phpNie można pobrać prawdziwego pliku.
Jest zatem oczywiste, że wyprowadzenie się wp-config.phppoza root root ma prawdziwe zalety bezpieczeństwa w prawdziwym świecie .
Jak przenieść wp-config.phpsię w dowolne miejsce na serwerze
WordPress automatycznie wyszuka jeden katalog nad instalacją WordPressa, aby znaleźć wp-config.phpplik, więc jeśli tam właśnie go przeniesiłeś, to gotowe!
Ale co, jeśli przeniosłeś go gdzieś indziej? Łatwo. Utwórz nowy wp-config.phpw katalogu WordPress za pomocą następującego kodu:
<?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');
(Pamiętaj, aby zmienić powyższą ścieżkę na rzeczywistą ścieżkę przeniesionego wp-config.phppliku).
Jeśli napotkasz problem open_basedir, po prostu dodaj nową ścieżkę do open_basedirdyrektywy w konfiguracji PHP:
open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"
Otóż to!
Oddzielanie argumentów przeciwnych
Każdy argument przemawiający za wyjściem wp-config.phppoza katalog główny zależy od fałszywych założeń.
Argument 1: Jeśli PHP jest wyłączone, są już włączone
Jedynym sposobem, aby ktoś zobaczył zawartość [ wp-config.php], jest obejście twoich serwerów. Tłumacz PHP… Jeśli tak się stanie, masz już kłopoty: mają bezpośredni dostęp do twojego serwera.
FAŁSZ : Scenariusz, który opisuję powyżej, jest wynikiem błędnej konfiguracji, a nie wtargnięcia.
Argument 2: Przypadkowe wyłączenie PHP jest rzadkie, a zatem nieistotne
Jeśli osoba atakująca ma wystarczający dostęp, aby zmienić moduł obsługi PHP, już masz problemy. Przypadkowe zmiany są bardzo rzadkie z mojego doświadczenia i w takim przypadku łatwo byłoby zmienić hasło.
FALSE : Scenariusz, który opisuję powyżej, jest wynikiem błędu w wspólnym oprogramowaniu serwera, który wpływa na wspólną konfigurację serwera. Nie jest to rzadko „rzadkie” (a poza tym bezpieczeństwo oznacza martwienie się o rzadki scenariusz).
WTF : Zmiana hasła po włamaniu nie pomaga, jeśli poufne informacje zostały wykryte podczas włamania. Naprawdę, czy nadal uważamy, że WordPress jest używany tylko do zwykłego blogowania i że atakujący są zainteresowani tylko deflacją? Martwmy się o ochronę naszego serwera, a nie tylko przywracanie go po wejściu kogoś.
Argument 3: Odmowa dostępu wp-config.phpjest wystarczająco dobra
Możesz ograniczyć dostęp do pliku za pomocą konfiguracji wirtualnego hosta lub
.htaccess- skutecznie ograniczając dostęp do pliku z zewnątrz w taki sam sposób, jak by to miało miejsce poza katalogiem głównym dokumentu.
FAŁSZ : Wyobraź sobie domyślnych serwera dla wirtualnego hosta są: brak PHP, no .htaccess, allow from all(prawie niezwykłe w środowisku produkcyjnym). Jeśli konfiguracja zostanie w jakiś sposób zresetowana podczas rutynowej operacji - na przykład aktualizacji panelu - wszystko powróci do stanu domyślnego, a użytkownik zostanie wykryty.
Jeśli Twój model bezpieczeństwa zawiedzie, gdy ustawienia zostaną przypadkowo przywrócone do wartości domyślnych, potrzebujesz więcej zabezpieczeń.
WTF : Dlaczego ktoś miałby szczególnie polecać mniej warstw bezpieczeństwa? Drogie samochody mają nie tylko zamki; mają także alarmy, immobilizery i urządzenia śledzące GPS. Jeśli coś jest warte ochrony, zrób to dobrze.
Argument 4: Nieautoryzowany dostęp do wp-config.phpto nic wielkiego
Informacje w bazie danych to tak naprawdę jedyne wrażliwe rzeczy w [ wp-config.php].
FALSE : Klucze uwierzytelniające i sole mogą być użyte w dowolnej liczbie potencjalnych ataków porwania.
WTF : Nawet jeśli poświadczenia bazy danych były jedyną rzeczą wp-config.php, powinieneś się bać atakującego.
Argument 5: Przeniesienie wp-config.phppoza główny katalog internetowy faktycznie sprawia, że serwer jest mniej bezpieczny
Nadal musisz zezwolić WordPressowi na dostęp [ wp-config.php], więc musisz rozwinąć, open_basediraby uwzględnić katalog powyżej katalogu głównego dokumentu.
FALSE : Zakładając, że wp-config.phpjest włączony httpdocs/, po prostu przenieś go ../phpdocs/i ustaw, open_basediraby zawierał tylko httpdocs/i phpdocs/. Na przykład:
open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"
(Pamiętaj, aby zawsze dołączać katalog /tmp/użytkownika tmp/, jeśli go masz).
Wniosek: pliki konfiguracyjne zawsze powinny zawsze znajdować się poza katalogiem głównym
Jeśli zależy Ci na bezpieczeństwie, przeprowadzisz się wp-config.phppoza swój katalog główny.