Czy przeniesienie wp-config poza katalog główny jest naprawdę korzystne?

135

Jedną z najczęstszych najlepszych praktyk bezpieczeństwa w dzisiejszych czasach wydaje się być przenoszenie o wp-config.phpjeden katalog wyżej niż katalog główny vhosta . Nigdy tak naprawdę nie znalazłem dobrego wytłumaczenia tego, ale zakładam, że minimalizuje to ryzyko złośliwego lub zainfekowanego skryptu w katalogu głównym od odczytu hasła do bazy danych.

Ale nadal musisz pozwolić WordPressowi na dostęp, więc musisz rozwinąć, open_basediraby uwzględnić katalog powyżej katalogu głównego dokumentu. Czy to nie tylko pokonuje cały cel, a także potencjalnie naraża atakujące dzienniki serwera, kopie zapasowe itp.?

Czy też technika ta stara się tylko zapobiec sytuacji, w której wp-config.phpkażdy http://example.com/wp-config.php, kto o to poprosi, będzie wyświetlany jako zwykły tekst , zamiast być analizowanym przez silnik PHP? Wydaje się, że jest to bardzo rzadkie zdarzenie i nie przeważałoby to nad wadami narażania dzienników / kopii zapasowych / etc na żądania HTTP.

Może można przenieść go poza katalog główny dokumentu w niektórych konfiguracjach hostingu bez ujawniania innych plików, ale nie w innych konfiguracjach?

Wniosek: po wielu dyskusjach w tej sprawie pojawiły się dwie odpowiedzi, które moim zdaniem należy uznać za autorytatywne. Aaron Adams czyni dobrą sprawę na korzyść ruchu wp-config i chrisguitarguymakes dobrą sprawę przeciwko nim . Są to dwie odpowiedzi, które powinieneś przeczytać, jeśli jesteś nowy w wątku i nie chcesz czytać całej rzeczy. Inne odpowiedzi są zbędne lub niedokładne.

security customization wp-config Ian Dunn
źródło
Naprawdę nie jest konieczne podłączanie wybranych odpowiedzi i odrzucanie wszystkich innych odpowiedzi wewnątrz pytania. Jak widać poniżej, po to jest system głosowania wymiany stosów, aby głosować na odpowiedzi, które mają sens dla ludzi, podczas gdy osoby zadające pytania powinny korzystać z mechanizmu „zaakceptowanej odpowiedzi” i własnych głosów w górę / w dół.
Kzqai
6
Nie robię tego w 99% zadanych przeze mnie pytań, ale uważałem, że w tym konkretnym przypadku jest to właściwe. Istnieje 8 odpowiedzi na to pytanie, z których niektóre są dość długie / złożone, a niektóre mają wiele pozytywnych opinii, pomimo że zawierają niedokładne informacje lub nie dodają niczego do rozmowy. Myślę, że zaproponowanie półautorytatywnych wniosków jest pomocne dla osób czytających wątek po raz pierwszy. Jak zawsze, czytelnicy mają swobodę w podejmowaniu decyzji; Po prostu oferuję swoją opinię jako OP.
Ian Dunn
1
@Kzqai: „System głosowania wymiany stosów” jest procesem demokratycznym, a uczestnicy często 1) nie są pewni, o co OP właściwie pyta lub próbuje rozwiązać, oraz 2) nie rozumieją ważności konkretnej odpowiedzi. Po wkroczeniu odpowiedzi i oddaniu głosów bardzo pomocne jest, aby PO wyjaśnił odpowiedzi, które udzieliły pomocy. W końcu PO jest jedynym, który wie i chciałbym, żeby więcej PO to zrobiło. Tak, ludzie „głosują na odpowiedzi, które mają sens dla ludzi”, ale pozwólmy OP mieć ostatnie słowo, co ma dla niego sens.
Mac

Odpowiedzi:

127

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:

  1. Skonfiguruj poddomenę, aby przekierowywać na inny adres URL (np. site.staging.server.comDo site-staging.ssl.server.com).
  2. 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.

Aaron Adams
źródło
1
Jeśli masz błąd w apache, Linux lub mózgu administratora, to i tak jesteś toastem. W twoim scenariuszu nie wyjaśniasz, dlaczego bardziej prawdopodobne jest, że doszło do błędnej konfiguracji w katalogu głównym witryny, a nie w jakimkolwiek innym miejscu na serwerze. Błędnie skonfigurowany apache może uzyskać dostęp do /../config.php tak łatwo, jak /config.php
Mark Kaplun,
1
W każdym razie nie jesteś „tostem”. Jest bardzo prawdopodobne , a nawet możliwe do udowodnienia , że błąd spowoduje zresetowanie katalogu głównego do jego wartości domyślnej, w którym to przypadku nie będziesz „wznosił toastu” - wp-config.phppozostaniesz bezpieczny. I jest to bardzo nieprawdopodobne - tak bardzo, że w zasadzie jest niemożliwe - że błąd spowodowałby arbitralne zresetowanie katalogu głównego do dokładnego katalogu, w którym został umieszczony wp-config.php.
Aaron Adams,
1
@IanDunn W rzeczywistości łatwo jest przenieść wp-config.phpsię w dowolne miejsce. Dodałem wskazówki do mojej odpowiedzi; polega po prostu na stworzeniu manekina wp-config.phpw katalogu WordPress z odniesieniem do położenia prawdziwego.
Aaron Adams,
3
Ta odpowiedź jest natychmiastowa. Moja firma hostingowa miała awarię macierzy dysków. Kiedy wszystko zostało powiedziane i zrobione, przywrócili system CZĘŚCIOWO. Okazuje się, że użyli serii skryptów cPanel / WHM do odbudowania plików httpd.conf, które zrobiły to niepoprawnie. Na szczęście miałem już wp-config.php poza katalogiem głównym dokumentu, ale gdybym tego nie zrobił, zawartość była tam do wzięcia. Tak rzadko, ale jak wspomniano, rzadkie przypadki są tym, o co musisz się martwić. Również stwierdzenie, że „ludzie o prostym umyśle by się zgubili” jest złym usprawiedliwieniem dla MNIEJ bezpieczeństwa.
Lance Cleveland,
1
To dobra uwaga, Aaron. Nadal jestem trochę sceptyczny z powodów, o których wspomniałem w tym i innym wątku komentarza, ale przekonałeś mnie, że ma więcej zalet, niż początkowo myślałem. Przynajmniej, jeśli zrobione właściwie, nie sądzę, żeby coś to zaszkodziło. Nadal mam problem z tym, że większość promujących go osób nie rozumie ich przyczyn, a sposób, w jaki je uczą, często prowadzi do ujawnienia katalogu powyżej httpdocs, ale pomogłeś rozwiązać te problemy w Twoja odpowiedź.
Ian Dunn,
40

Najważniejsze jest to, że wp-config.phpzawiera pewne poufne informacje: nazwa użytkownika / hasło bazy danych itp.

Pomysł: przenieś go poza katalog główny dokumentu i nie musisz się o nic martwić. Osoba atakująca nigdy nie będzie mogła uzyskać dostępu do tego pliku z zewnętrznego źródła.

Oto jednak pociecha: wp-config.phptak naprawdę nigdy nie drukuje niczego na ekranie. Definiuje tylko różne stałe, które są używane podczas instalacji WP. Dlatego jedynym sposobem, aby ktoś zobaczył zawartość tego pliku, jest obejście interpretera PHP na serwerach - .phpplik jest renderowany jako zwykły tekst. Jeśli tak się stanie, masz już kłopoty: mają bezpośredni dostęp do twojego serwera (i prawdopodobnie uprawnienia roota) i mogą robić, co chcą.

Zamierzam powiedzieć, że nie ma korzyści zwp-config wychodzenia poza katalog główny dokumentu z perspektywy bezpieczeństwa - z powyższych powodów i tych:

  1. Możesz ograniczyć dostęp do pliku za pomocą konfiguracji hosta wirtualnego lub .htaccess - skutecznie ograniczając zewnętrzny dostęp do pliku w taki sam sposób, jak w przypadku przeniesienia poza katalog główny dokumentu
  2. Możesz upewnić się, że uprawnienia do plików są ściśle określone, wp-configaby uniemożliwić każdemu użytkownikowi bez wystarczających uprawnień odczytanie pliku, nawet jeśli uzyska (ograniczony) dostęp do twojego serwera przez SSH.
  3. Twoje poufne informacje, ustawienia bazy danych, są używane tylko w jednej witrynie. Więc nawet jeśli atakujący uzyska dostęp do tych informacji, jedyną witryną, na którą wpłynie, będzie instalacja WordPress, do której wp-config.phpnależy plik. Co ważniejsze, ten użytkownik bazy danych ma tylko uprawnienia do odczytu i zapisu w bazie danych instalacji WP i nic więcej - nie ma dostępu do udzielania uprawnień innym użytkownikom. Innymi słowy, jeśli osoba atakująca uzyska dostęp do bazy danych, wystarczy przywrócić dane z kopii zapasowej (patrz punkt 4) i zmienić użytkownika bazy danych
  4. Często tworzysz kopie zapasowe. Często jest to termin względny: jeśli publikujesz 20 artykułów każdego dnia, lepiej tworzyć kopie zapasowe każdego dnia lub co kilka dni. Jeśli publikujesz raz w tygodniu, tworzenie kopii zapasowych raz w tygodniu jest prawdopodobnie wystarczające.
  5. Twoja witryna jest pod kontrolą wersji ( taką jak ta ), co oznacza, że ​​nawet jeśli osoba atakująca uzyska dostęp, możesz łatwo wykryć zmiany kodu i przywrócić je. Jeśli atakujący ma dostęp wp-config, prawdopodobnie pomieszał coś innego.
  6. Informacje z bazy danych są naprawdę jedynymi wrażliwymi danymi wp-config, a ponieważ jesteś ostrożny (patrz punkty 3 i 4), nie jest to wielka sprawa. Sole i takie można zmienić w dowolnym momencie. Jedyne, co się dzieje, to to, że unieważnia pliki cookie zalogowanych użytkowników.

Dla mnie wp-configwyjście z korzenia dokumentu cuchnie bezpieczeństwem przez niejasność - co jest bardzo słabym człowiekiem.

chrisguitarguy
źródło
2
Tak, właściwie o tym myślałem. Cieszę się, że nie jestem jedyny :) Chciałbym zostawić pytanie otwarte na kolejny dzień lub dwa na wypadek, gdyby ktoś miał przekonujący kontrargument, ale jak dotąd wydaje się to właściwą odpowiedzią na mnie.
Ian Dunn
3
Drobna korekta: Przeniesienie pliku wp-config.php z katalogu głównego dokumentu nie ma żadnej korzyści dla bezpieczeństwa . Istnieją inne korzyści, które nie są związane z bezpieczeństwem i dotyczą tylko nietypowych konfiguracji.
Otto,
4
Żeby obalić możliwy mit - czy to niemożliwe, coś może pójść nie tak po stronie serwera - w którym to przypadku kod php jest drukowany na ekranie?
Stephen Harris
3
@IanDunn Ale najlepsze odpowiedzi przemawiają za przeniesieniem go całkowicie z tej hierarchii do osobnej, co rozwiąże Twoje obawy związane z logami itp. Ta odpowiedź nie odpowiada na pytanie, które brzmi „porusza się ... naprawdę korzystne”, po prostu mówi inne środki bezpieczeństwa są korzystne i próbują cię uspokoić, abyś nie martwił się o bezpieczeństwo. Wszyscy myślą, że ich dom jest bezpieczny, dopóki nie zostaną włamani. Potem wykonują lepszą pracę. Niektóre osoby nigdy nie zostają włamane, mimo że ich bezpieczeństwo jest niskie, ale to nie znaczy, że dobrą radą jest mieć niższe bezpieczeństwo.
AndrewC
4
To są dobre strony, ale moim największym problemem jest to, że są to argumenty naprawcze, a nie prewencyjne. Większość z nich mówi o tym, że to nie jest wielka sprawa, ponieważ A) zakładasz, że ktoś poprawnie obsługiwał użytkownika db, a B) masz kopie zapasowe. Co się dzieje, gdy używasz czegoś takiego jak woocommerce lub przechowujesz poufne informacje w swojej bazie danych? Więc jesteś pieprzony.
Goldentoa11
25

Myślę, że Max jest kompetentną odpowiedzią, a to jedna strona historii. WordPress Codex ma więcej porad :

Upewnij się także, że tylko Ty (i serwer sieciowy) możesz odczytać ten plik (zazwyczaj oznacza to uprawnienie 400 lub 440).

Jeśli korzystasz z serwera z rozszerzeniem .htaccess, możesz umieścić ten plik w tym pliku (na samej górze), aby odmówić dostępu każdemu, kto go przegląda:

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

Pamiętaj, że ustawienie uprawnień 400 lub 440 na wp-config.php może uniemożliwić wtyczkom zapisywanie lub modyfikowanie go. Prawdziwym przypadkiem byłoby na przykład buforowanie wtyczek (W3 Total Cache, WP Super Cache itp.) W takim przypadku wybrałbym 600 (domyślne uprawnienie do plików w /home/userkatalogu).

to ja
źródło
5
Odpowiedź Maxa. +1 do niego. Po prostu staram się go przedłużyć.
its_me
1
Aahan Krish, trafiłeś w dziesiątkę. Dzięki za dodanie.
Max Yudin
Więc jeśli używasz htaccess do odrzucania żądań HTTP do wp-config.php, czy to nie osiąga takiego samego rezultatu jak przeniesienie go poza katalog główny dokumentu, ale bez ujawnienia dzienników / kopii zapasowych / etc?
Ian Dunn
4
@IanDunn Zależy od tego, czym jest katalog główny - (1) Jeśli Wordpress jest hostowany w katalogu wewnątrz public_html, przejście wp-config.phppoza katalog oznacza, że ​​będzie on w public_htmlkatalogu. W takim przypadku musisz użyć reguł htaccess, aby odrzucić żądania HTTP do wp-config.php. (2) Jeśli WordPress jest zainstalowany bezpośrednio w public_htmlkatalogu, o jeden poziom wyżej => przeniesiesz go do /home/userkatalogu. W tym przypadku jesteś całkiem bezpieczny, ponieważ plik znajduje się poza katalogiem głównym dokumentu. Nadal możesz ustawić uprawnienia do pliku na 600 (lub nawet bardziej rygorystyczne 440 lub 400).
its_me
@IanDunn Tak jak powiedziałem, to moje podstawowe zrozumienie i nie jestem ekspertem od bezpieczeństwa. :)
its_me
17

Ktoś poprosił nas, żebyśmy zabłysnęli, a ja odpowiem tutaj.

Tak, izolacja pliku wp-config.php od katalogu głównego witryny ma zalety bezpieczeństwa.

1- Jeśli Twój program obsługi PHP zostanie uszkodzony lub zmodyfikowany w jakiś sposób, informacje DB nie zostaną ujawnione. I tak, widziałem to kilka razy na współdzielonych hostach podczas aktualizacji serwera. Tak, witryna zostanie zepsuta w tym okresie, ale hasła pozostaną nienaruszone.

2- Najlepsze praktyki zawsze zalecają izolowanie plików konfiguracyjnych od plików danych. Tak, trudno to zrobić za pomocą WordPress (lub dowolnej aplikacji internetowej), ale przeniesienie go w górę powoduje nieco izolacji.

3- Pamiętaj o wrażliwości na PHP-CGI, gdzie każdy może przekazać? -S do pliku i wyświetlić źródło. http://www.kb.cert.org/vuls/id/520827

Na koniec są to drobne szczegóły, ale pomagają zminimalizować ryzyko. Zwłaszcza jeśli jesteś we wspólnym środowisku, w którym każdy może uzyskać dostęp do twojej bazy danych (wszystko czego potrzebuje to użytkownik / przepustka).

Ale nie pozwól, aby małe rozproszenia (przedwczesne optymalizacje) znalazły się przed tym, co jest naprawdę konieczne, aby witryna była odpowiednio bezpieczna:

1 - Zawsze aktualizuj

2- Użyj silnych haseł

3- Ogranicz dostęp (poprzez uprawnienia). Mamy tutaj post na ten temat:

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

dzięki,

Sucuri
źródło
Cześć wszystkim, dziękuję, że dodaliście swoje przemyślenia. Myślę, że już trafiliśmy na większość tych punktów w innych odpowiedziach i ich komentarzach. 1) Tak, jest to możliwe, ale rzadkie; 2) Tak, ma to zalety, ale są minimalne; 3) Tak, jest to możliwe, ale taka podatność na zagrożenia raczej się nie powtórzy, a ochrona przed nią przypomina zabawę w pieprzyk lub zmuszanie ludzi do zdejmowania butów na lotniskach, ponieważ jakiś jackass ukrył bombę w swoim but raz. Jest reakcyjny i mało prawdopodobne, aby przyniósł w przyszłości korzyści.
Ian Dunn,
W różnych dyskusjach dopracowano pytanie z „Czy są jakieś korzyści?” na „Ok, są pewne korzyści, ale czy przewyższają ryzyko?” Główne ryzyko, o którym mówię, to fakt, że musisz rozszerzyć zakres openbase_dir, aby umożliwić PHP dostęp do skryptów poza katalogiem głównym. Wiele ustawień hostingu - w tym te, które używają Plesk, które jest dużo - przechowują dzienniki, kopie zapasowe, prywatne obszary FTP, które powinny być izolowane od katalogu głównego itp. W katalogu nad katalogiem głównym. Tak więc udzielenie PHP dostępu do tego katalogu może być poważną luką.
Ian Dunn,
15

Zdecydowanie tak.

Kiedy przenosisz wp-config.php poza katalog publiczny, zabezpieczysz go przed czytaniem za pomocą przeglądarki, gdy program obsługi php zostanie złośliwie (lub przypadkowo!) Zmieniony.

Odczytywanie loginu / hasła do bazy danych jest możliwe, gdy serwer jest prawie zainfekowany z winy słabego administratora. Nałóż na administratora grzywnę i uzyskaj lepiej utrzymany i bardziej niezawodny serwer. Chociaż może to być droższe.

Max Yudin
źródło
4
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. Czy w świetle tych rzeczy nadal uważasz, że warto ryzykować ujawnienie dzienników / kopii zapasowych / etc z powodu rozszerzonego open_basedirzakresu?
Ian Dunn
1
Nigdy nie miałem -rwxdostępu do katalogów wyższych niż, public_htmlwięc nigdy się nie znałem open_basedir. Moje dzienniki znajdują się w osobnym katalogu, więc kopie zapasowe też. Myślę, że właśnie to mają wszyscy współdzieleni hosty.
Max Yudin
Gospodarze różnią się bardzo; nie ma standardowej struktury katalogów. Plesk (jeden z najpopularniejszych paneli sterowania dla współdzielonych hostów) umieszcza dzienniki w /var/www/vhosts/example.com/statistics/logs, a katalogiem głównym jest /var/www/vhosts/example.com/httpdocs. Przeniesienie wp-config.php do /var/www/vhosts/example.com/wp-config.php wymagałoby udostępnienia skryptom dostępu do całego katalogu example.com.
Ian Dunn
Tylko z ciekawości, gdzie są przechowywane twoje dzienniki i kopie zapasowe, jeśli nie w katalogu domeny? Czy można uzyskać do nich dostęp za pośrednictwem panelu sterowania lub czegoś takiego?
Ian Dunn
1
Tak, za pomocą panelu sterowania.
Max Yudin
8

Chciałbym tylko wyjaśnić, ze względu na argument, że przeniesienie pliku wp_config.php niekoniecznie oznacza, że ​​musisz przenieść go tylko do katalogu nadrzędnego. Załóżmy, że masz strukturę taką jak / root / html, gdzie html zawiera instalację WP i całą zawartość HTML. Zamiast przenieść wp_config.php do / root, możesz przenieść go do czegoś takiego jak / root / secure ... który znajduje się zarówno poza katalogiem html, jak również poza katalogiem głównym serwera. Oczywiście musisz upewnić się, że php może również działać w tym bezpiecznym folderze.

Ponieważ WP nie można skonfigurować do wyszukiwania wp_config.php w folderze rodzeństwa, takim jak / root / secure, musisz wykonać dodatkowy krok. Zostawiłem wp_config.php w / root / html i wyciąłem wrażliwe części (login bazy danych, sól, prefiks tabeli) i przeniosłem je do osobnego pliku o nazwie config.php. Następnie dodajesz includepolecenie PHP do pliku wp_config.php, w następujący sposób:include('/home/content/path/to/root/secure/config.php');

Zasadniczo to zrobiłem w mojej konfiguracji. Teraz, na podstawie powyższej dyskusji, wciąż oceniam, czy jest to konieczne, czy nawet dobry pomysł. Chciałem tylko dodać, że powyższa konfiguracja jest możliwa. Nie ujawnia kopii zapasowych i innych plików głównych, a tak długo, jak bezpieczny folder nie ma własnego publicznego adresu URL, nie można go przeglądać.

Ponadto możesz ograniczyć dostęp do bezpiecznego folderu, tworząc tam plik .htaccess za pomocą:

order deny,allow
deny from all
allow from 127.0.0.1
Michael
źródło
Hej Michael, dzięki za podzielenie się tym. Czy wypróbowałeś go jednak w prawdziwym środowisku, aby sprawdzić, czy działa? Myślę, że open_basedirdyrektywa zajmuje całe drzewa , tak aby uzyskać dostęp /root/securez /root/html, trzeba ustawić open_basedirsię /root.
Ian Dunn
Aby twój pomysł zadziałał, myślę, że musisz skonfigurować strukturę katalogów /root/httpdocs/config/accessible, w której httpdocsznajdują się dzienniki, kopie zapasowe itp .; configprzechowuje wp-config.phpi accessibleprzechowuje WordPress i całą zawartość. Będziesz musiał zmodyfikować konfigurację vhost itp., Aby zmienić mapowanie katalogu głównego dokumentu accessible. Nie widzę jednak żadnej korzyści z samego odrzucenia żądań HTTP do wp-config w domyślnej konfiguracji.
Ian Dunn
1
Według php.net/manual/en/ini.core.php#ini.open-basedir : „W systemie Windows oddziel katalogi średnikiem. We wszystkich innych systemach oddziel katalogi dwukropkiem. Jako moduł Apache, ścieżki open_basedir z katalogów nadrzędnych są teraz automatycznie dziedziczone. " Możesz więc ustawić wiele katalogów, nie musisz znajdować się w jednym drzewie.
Michael
Właśnie to przetestowałem i wygląda na to, że masz rację. Nadal nie jestem jednak pewien, jakie korzyści dla bezpieczeństwa ma to po prostu odmowa dostępu do pliku przez Apache.
Ian Dunn
@IanDunn dobrze przemówił w odpowiedzi Aarona Adamsa
AndrewC
4

Istnieje wiele źle napisanych motywów i wtyczek, które pozwalają atatckerom wstrzykiwać kod (pamiętaj o problemie bezpieczeństwa z Timthumbem). Jeśli miałbym być atakującym, dlaczego powinienem szukać wp-config.php? Wystarczy wstrzyknąć ten kod:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Możesz spróbować ukryć swój wp-config.php. Tak długo, jak WordPress udostępnia wszystkie poufne informacje globalnie, ukrywanie pliku wp-config.php nie ma żadnej korzyści.

Zła część wp-config.php nie polega na tym, że przechowuje poufne dane. Złą częścią jest zdefiniowanie wrażliwych danych jako globalnie dostępnej stałej.

Aktualizacja

Chcę wyjaśnić problemy define()i dlaczego definiowanie wrażliwych danych jako stałej globalnej jest złym pomysłem.

Istnieje wiele sposobów na atak na stronę internetową. Zastrzyk skryptu to tylko jeden sposób na zaatakowanie strony internetowej.

Zakładając, że serwer ma lukę, która pozwala osobie atakującej uzyskać dostęp do zrzutu pamięci. Atakujący znajdzie w pamięci zrzut wszystkich wartości wszystkich zmiennych. Jeśli zdefiniujesz globalnie dostępną stałą, musi ona pozostać w pamięci aż do zakończenia skryptu. Po utworzeniu zmiennej zamiast stałej istnieje duże prawdopodobieństwo, że śmieciarz nadpisze (lub zwolni) pamięć, gdy zmienna nie jest już potrzebna.

Lepszym sposobem ochrony wrażliwych danych jest usunięcie ich natychmiast po ich użyciu:

$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;

Po użyciu wrażliwych danych przypisanie do nullspowoduje zastąpienie danych w pamięci. Osoba atakująca musi uzyskać zrzut pamięci w momencie, gdy $db_conzawiera poufne dane. I to jest bardzo krótki czas w powyższym przykładzie (jeśli klasa Database_Handler nie zapisuje jej kopii).

Ralf912
źródło
Ta odpowiedź nie odnosi się bezpośrednio do pytania. Każdy autor wtyczek może skorzystać z WordPress, jeśli przekona cię do zainstalowania swojego kodu i będzie miał złośliwe zamiary. Nie różni się to od dobrowolnej instalacji wirusa w systemie. Ten argument, aby nie przenosić wp-config.php, jest bezcelowy. To tak, jakby powiedzieć, że umyślne zainstalowanie bomby samochodowej w samochodzie sprawia, że ​​ustawienie alarmu samochodowego jest bezużyteczne. Technicznie prawda, ale WTF?!?
Lance Cleveland,
2
Nie, to nie ma sensu. Pytanie brzmi: czy mogę chronić konto bazy danych, ukrywając plik wp-config.php. Odpowiedź jest jednoznaczna: nie. Jest tak samo, jakbyś zapytał: „Czy mogę zabezpieczyć swój samochód przed bombami samochodowymi za pomocą alarmu samochodowego?”. Nie ma innych korzyści, ukrywając konfigurację wp-config jako ochronę dostępu do bazy danych lub dostępu ftp. Oba mają zasięg globalny. Jestem pewien, że atakujący mają więcej sposobów na uzyskanie dostępu do globalnych zmiennych bez wstrzykiwania kodu.
Ralf912,
Nie widzę „Czy mogę chronić konto bazy danych, ukrywając wp-config.php” w pierwotnym pytaniu. Pierwotne pytanie brzmiało: „czy sensowne jest przeniesienie wp-config.php”. Odpowiedź brzmi absolutnie tak, IMO. To jest jak pytanie, czy powinieneś zamknąć drzwi wejściowe, kiedy wychodzisz. Powiedzenie „ktoś może łatwo wybić okno i wejść, więc po co zawracać sobie głowę”, nie odpowiada na zasadniczy punkt pytania. IMO zadało następujące pytanie: „Czy warto włożyć dodatkowy wysiłek, aby przenieść wp-config.php? JAKĄKOLWIEK korzyści?”. Tak. Przynajmniej powstrzymuje leniwych hakerów.
Lance Cleveland,
2
Jedna z najczęstszych najlepszych praktyk bezpieczeństwa ... Przegapiłeś bardzo (bardzo, bardzo) ważną kwestię: na czym zainteresowany jest atakujący? I nie tak stylizujesz swój wp-config.php. Atakującym interesują się wartości zdefiniowane w wp-config. Chwyć swój przykład za pomocą drzwi wejściowych: Ukrywanie wp-config jest takie samo, jakbyś zamknął drzwi wejściowe, ale przechowuje całe swoje złoto bez ochrony w ogrodzie. Wszystkie wartości zdefiniowane w wp-config są zdefiniowane globalnie . Wszystkie są dostępne poza wp-config. Nawet jeśli ukryjesz swoją wp-config, wartości są nadal obecne.
Ralf912,
1
Myślę, że ci, którzy opowiadają się za jego przeniesieniem, próbują zabezpieczyć się przed scenariuszami, w których wp-config.php może być wyświetlany zwykłym tekstem za pośrednictwem żądania HTTP, a nie scenariuszami, w których może być narażony na działanie innego kodu PHP działającego na hoście.
Ian Dunn,
-1

Oprócz korzyści związanych z bezpieczeństwem, pozwala również zachować instancję WordPress pod kontrolą wersji, jednocześnie zachowując podstawowe pliki WordPress jako submoduł / zewnętrzny. W ten sposób Mark Jaquith skonfigurował swój projekt WordPress-Skeleton. Szczegółowe informacje można znaleźć na stronie https://github.com/markjaquith/WordPress-Skeleton#assumptions .

Emzo
źródło
8
Ma to ustawione w katalogu głównym dokumentu, a nie poza nim, więc nie ma to związku z tym pytaniem. Technika, o którą zadano pytanie, określa, że ​​przenosisz wp-config.phpjeden katalog powyżej katalogu głównego vhosta , a nie tylko jeden katalog powyżej folderu instalacyjnego WordPress. Chodzi o to, aby umieścić go poza folderem, który może być odczytany przez żądania HTTP.
Ian Dunn