Apakah memindahkan wp-config di luar root web benar-benar bermanfaat?

135

Salah satu praktik terbaik keamanan paling umum akhir-akhir ini tampaknya memindahkan wp-config.phpsatu direktori lebih tinggi daripada root dokumen vhost . Saya tidak pernah benar-benar menemukan penjelasan yang baik untuk itu, tetapi saya berasumsi itu untuk meminimalkan risiko skrip berbahaya atau terinfeksi dalam webroot dari membaca kata sandi basis data.

Tapi, Anda masih harus membiarkan WordPress mengaksesnya, jadi Anda perlu memperluas open_basediruntuk memasukkan direktori di atas root dokumen. Bukankah itu hanya mengalahkan seluruh tujuan, dan juga berpotensi mengekspos log server, cadangan, dll untuk penyerang?

Atau teknik ini hanya mencoba untuk mencegah situasi di mana wp-config.phpakan ditampilkan sebagai teks biasa kepada siapa pun yang meminta http://example.com/wp-config.php, alih-alih diurai oleh mesin PHP? Itu tampak seperti kejadian yang sangat langka, dan itu tidak akan melebihi kerugian dari mengekspos log / backup / etc untuk permintaan HTTP.

Mungkin dimungkinkan untuk memindahkannya di luar root dokumen di beberapa pengaturan hosting tanpa mengekspos file lain, tetapi tidak pada pengaturan lainnya?

Kesimpulan: Setelah banyak bolak-balik tentang masalah ini, muncul dua jawaban yang menurut saya harus dianggap sebagai yang berwibawa. Aaron Adams membuat kasus yang baik dalam mendukung wp-config, dan chrisguitarguymakes kasus yang bagus untuk menentangnya . Itulah dua jawaban yang harus Anda baca jika Anda baru di utas dan tidak ingin membaca semuanya. Jawaban lainnya adalah redundan atau tidak akurat.

security customization wp-config Ian Dunn
sumber
Ini benar-benar tidak perlu untuk memasukkan pilihan jawaban Anda dan menolak semua jawaban lain, di dalam pertanyaan Anda. Seperti yang Anda lihat di bawah, itulah gunanya sistem pemungutan suara stackexchange, untuk memilih jawaban yang masuk akal bagi orang-orang, sedangkan penanya pertanyaan harus menggunakan mekanisme "jawaban yang diterima" dan suara naik / turun Anda sendiri.
Kzqai
6
Saya tidak melakukan itu untuk 99% pertanyaan yang saya ajukan, tetapi saya pikir itu sesuai untuk kasus khusus ini. Ada 8 jawaban untuk pertanyaan, beberapa di antaranya cukup panjang / kompleks, dan beberapa di antaranya memiliki banyak upvotes meskipun mengandung informasi yang tidak akurat atau tidak menambahkan apa pun ke percakapan. Saya pikir menawarkan kesimpulan semi-otoritatif sangat membantu bagi orang yang membaca utas untuk pertama kalinya. Seperti biasa, pembaca bebas untuk mengambil keputusan sendiri; Saya hanya menawarkan pendapat saya sebagai OP.
Ian Dunn
1
@Kzqai: "sistem pemilihan stackexchange" adalah proses yang demokratis, dan para peserta seringkali 1) tidak jelas mengenai apa yang sebenarnya diminta atau coba dipecahkan oleh OP, dan 2) tidak memahami validitas jawaban tertentu. Setelah tanggapan masuk dan suara diberikan, akan lebih bermanfaat jika OP mengklarifikasi tanggapan yang memberikan bantuan. Bagaimanapun, OP adalah satu-satunya yang tahu, dan saya berharap lebih banyak OP melakukannya. Ya, orang-orang "memilih jawaban yang masuk akal bagi orang-orang," tapi mari kita biarkan OP memiliki kata terakhir tentang apa yang masuk akal baginya.
Mac

Jawaban:

127

Jawaban singkat: ya

Jawaban untuk pertanyaan ini adalah ya tegas , dan mengatakan sebaliknya sepenuhnya tidak bertanggung jawab .

Jawaban panjang: contoh dunia nyata

Izinkan saya untuk memberikan contoh yang sangat nyata, dari server saya yang sangat nyata, di mana pindah ke wp-config.phpluar root web secara khusus mencegah kontennya ditangkap .

Serangga:

Lihatlah deskripsi bug di Plesk ini (diperbaiki pada 11.0.9 MU # 27):

Plesk me-reset penerusan subdomain setelah menyinkronkan berlangganan dengan paket hosting (117199)

Kedengarannya tidak berbahaya, bukan?

Nah, inilah yang saya lakukan untuk memicu bug ini:

  1. Mengatur subdomain untuk mengarahkan ke URL lain (misalnya site.staging.server.comuntuk site-staging.ssl.server.com).
  2. Mengubah paket layanan berlangganan (mis. Konfigurasi PHP-nya).

Ketika saya melakukan ini, Plesk mereset subdomain ke default: menyajikan konten ~/httpdocs/, tanpa penerjemah (mis. PHP) aktif.

Dan saya tidak menyadarinya. Selama berminggu-minggu.

Hasil:

  • Dengan wp-config.phpdi root web, permintaan untuk /wp-config.phpmengunduh file konfigurasi WordPress.
  • Dengan di wp-config.phpluar root web, permintaan untuk /wp-config.phpmengunduh file yang sama sekali tidak berbahaya. File asli wp-config.phptidak dapat diunduh.

Jadi, jelas bahwa pindah ke wp-config.phpluar root web memiliki manfaat keamanan yang bonafid di dunia nyata .

Cara pindah wp-config.phpke lokasi mana pun di server Anda

WordPress akan secara otomatis mencari satu direktori di atas instalasi WordPress Anda untuk wp-config.phpfile Anda , jadi jika Anda memindahkannya, Anda sudah selesai!

Tetapi bagaimana jika Anda memindahkannya ke tempat lain? Mudah. Buat yang baru wp-config.phpdi direktori WordPress dengan kode berikut:

<?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');

(Pastikan untuk mengubah jalur di atas ke jalur sebenarnya dari wp-config.phpfile yang Anda pindahkan .)

Jika Anda mengalami masalah dengan open_basedir, tambahkan saja jalur baru ke open_basedirarahan dalam konfigurasi PHP Anda:

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

Itu dia!

Memilih argumen yang bertentangan

Setiap argumen yang menentang pindah ke wp-config.phpluar root web bergantung pada asumsi yang salah.

Argumen 1: Jika PHP dinonaktifkan, mereka sudah masuk

Satu-satunya cara seseorang akan melihat bahwa konten [ wp-config.php] adalah jika mereka menghindari server Anda penerjemah PHP ... Jika itu terjadi, Anda sudah dalam masalah: mereka memiliki akses langsung ke server Anda.

FALSE : Skenario yang saya jelaskan di atas adalah hasil dari kesalahan konfigurasi, bukan intrusi.

Argumen 2: Menonaktifkan PHP secara tidak sengaja jarang terjadi, dan karenanya tidak signifikan

Jika penyerang memiliki akses yang cukup untuk mengubah handler PHP, Anda sudah kacau. Perubahan yang tidak disengaja sangat langka dalam pengalaman saya, dan dalam hal ini akan mudah untuk mengubah kata sandi.

SALAH : Skenario yang saya jelaskan di atas adalah hasil dari bug di bagian umum dari perangkat lunak server, yang mempengaruhi konfigurasi server umum. Ini hampir tidak "langka" (dan selain itu, keamanan berarti mengkhawatirkan skenario yang jarang terjadi).

WTF : Mengubah kata sandi setelah intrusi sangat membantu jika informasi sensitif diambil selama intrusi. Sungguh, apakah kita masih berpikir WordPress hanya digunakan untuk blogging biasa, dan bahwa penyerang hanya tertarik pada deflasi? Mari kita khawatirkan melindungi server kita, bukan hanya mengembalikannya setelah seseorang masuk.

Argumen 3: Menolak akses ke wp-config.phpcukup baik

Anda dapat membatasi akses ke file melalui konfigurasi host virtual Anda atau .htaccess- secara efektif membatasi akses luar ke file dengan cara yang sama seperti bergerak di luar root dokumen.

SALAH : Bayangkan default server Anda untuk host virtual adalah: tidak ada PHP, tidak .htaccess, allow from all(hampir tidak biasa dalam lingkungan produksi). Jika konfigurasi Anda entah bagaimana diatur ulang selama operasi rutin - seperti, katakanlah, pembaruan panel - semuanya akan kembali ke keadaan default, dan Anda terbuka.

Jika model keamanan Anda gagal ketika pengaturan secara tidak sengaja diatur ulang ke default, Anda memerlukan keamanan lebih.

WTF : Mengapa ada orang yang secara khusus merekomendasikan lebih sedikit lapisan keamanan? Mobil mahal tidak hanya memiliki kunci; mereka juga memiliki alarm, immobilizer, dan pelacak GPS. Jika ada sesuatu yang layak dilindungi, lakukan dengan benar.

Argumen 4: Akses tidak sah ke wp-config.phpbukan masalah besar

Informasi basis data adalah satu-satunya hal sensitif di [ wp-config.php].

SALAH : Kunci dan garam otentikasi dapat digunakan dalam sejumlah potensi serangan pembajakan.

WTF : Sekalipun kredensial basis data adalah satu-satunya yang ada di dalamnya wp-config.php, Anda harus takut penyerang akan mendapatkannya.

Argumen 5: Bergerak di wp-config.phpluar root web sebenarnya membuat server kurang aman

Anda masih harus membiarkan WordPress mengakses [ wp-config.php], jadi Anda perlu memperluas open_basediruntuk memasukkan direktori di atas root dokumen.

SALAH : Dengan asumsi wp-config.phpada httpdocs/, cukup pindahkan ke ../phpdocs/, dan setel open_basediruntuk menyertakan saja httpdocs/dan phpdocs/. Misalnya:

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

(Ingatlah untuk selalu memasukkan /tmp/, atau tmp/direktori pengguna Anda , jika Anda memilikinya.)

Kesimpulan: file konfigurasi harus selalu selalu selalu berada di luar akar web

Jika Anda peduli dengan keamanan, Anda akan pindah ke wp-config.phpluar root web Anda.

Aaron Adams
sumber
1
Jika Anda memiliki bug di apache, linux atau otak admin, Anda bersulang. Dalam skenario Anda, Anda gagal menjelaskan mengapa kesalahan konfigurasi terjadi pada akar situs web kemudian di tempat lain di server. Apache yang salah konfigurasi mungkin dapat mengakses /../config.php semudah /config.php
Mark Kaplun
1
Anda tidak "bersulang dalam hal apa pun." Sangat mungkin , dan bahkan dapat dibuktikan , bahwa bug akan mengakibatkan root web diatur ulang ke default, dalam hal ini Anda tidak "bersulang" - Anda wp-config.phptetap aman. Dan itu sangat mustahil - sangat banyak sehingga pada dasarnya tidak mungkin - bahwa bug akan mengakibatkan root web secara sewenang-wenang mengatur ulang ke direktori yang tepat di mana Anda menempatkan wp-config.php.
Aaron Adams
1
@IanDunn Sebenarnya, mudah untuk pindah wp-config.phpke lokasi yang sewenang-wenang. Saya telah menambahkan arah ke jawaban saya; itu hanya melibatkan membuat boneka wp-config.phpdi direktori WordPress referensi lokasi yang asli.
Aaron Adams
3
Tanggapan ini tepat. Perusahaan hosting web saya mengalami kegagalan array drive. Ketika semua dikatakan & dilakukan, mereka memulihkan sistem secara parsial. Ternyata mereka menggunakan serangkaian skrip cPanel / WHM untuk membangun kembali file httpd.conf yang melakukannya secara tidak benar. Untungnya saya sudah punya wp-config.php di luar root doc, tetapi jika saya tidak punya isinya ada untuk diambil. Ya jarang, tetapi seperti yang dicatat, kasus langka adalah hal yang perlu Anda khawatirkan. Juga, menyatakan "orang yang berpikiran sederhana akan hilang" adalah alasan buruk untuk memiliki keamanan KURANG.
Lance Cleveland
1
Itu poin yang bagus, Aaron. Saya masih sedikit skeptis untuk alasan yang saya sebutkan di utas ini dan komentar lainnya, tetapi Anda telah meyakinkan saya bahwa itu lebih bermanfaat daripada yang saya pikirkan. Paling tidak, jika dilakukan dengan benar, saya tidak berpikir itu akan menyakiti apa pun. Saya masih memiliki masalah dengan kenyataan bahwa sebagian besar orang yang mempromosikannya tampaknya tidak memahami alasannya, dan cara mereka mengajarkannya sering mengarah ke direktori di mana httpdocs terbuka, tetapi Anda telah membantu mengatasi masalah tersebut di jawabanmu.
Ian Dunn
40

Yang terbesar adalah wp-config.phpberisi beberapa informasi sensitif: nama pengguna / kata sandi database Anda, dll.

Jadi idenya: pindahkan di luar root dokumen, dan Anda tidak perlu khawatir tentang apa pun. Penyerang tidak akan pernah dapat mengakses file itu dari sumber eksternal.

Namun, inilah intinya: wp-config.phptidak pernah mencetak apa pun di layar. Ini hanya mendefinisikan berbagai konstanta yang digunakan di seluruh instalasi WP Anda. Dengan demikian satu-satunya cara seseorang akan melihat bahwa isi file itu adalah jika mereka menghindari server Anda penerjemah PHP - mereka mendapatkan .phpfile untuk di render sebagai hanya teks biasa. Jika itu terjadi, Anda sudah dalam masalah: mereka memiliki akses langsung ke server Anda (dan mungkin izin root) dan dapat melakukan apa pun yang mereka suka.

Saya akan melanjutkan dan mengatakan tidak ada manfaatnya untuk pindah ke wp-configluar akar dokumen dari perspektif keamanan - karena alasan di atas dan ini:

  1. Anda dapat membatasi akses ke file melalui konfigurasi host virtual atau .htaccess Anda - secara efektif membatasi akses luar ke file dengan cara yang sama seperti bergerak di luar root dokumen akan
  2. Anda dapat memastikan izin file ketat wp-configuntuk mencegah pengguna mana pun tanpa hak istimewa yang memadai untuk membaca file bahkan jika mereka mendapatkan akses (terbatas) ke server Anda melalui SSH.
  3. Informasi sensitif Anda, pengaturan basis data, hanya digunakan pada satu situs. Jadi, bahkan jika seorang penyerang mendapatkan akses ke informasi itu, satu-satunya situs yang akan terpengaruh adalah instalasi WordPress tempat wp-config.phpfile tersebut berada. Lebih penting lagi, bahwa pengguna basis data hanya memiliki izin untuk membaca dan menulis ke basis data instalasi WP dan dan tidak ada yang lain - tidak ada akses untuk memberikan izin pengguna lain. Artinya, dengan kata lain, jika penyerang mendapatkan akses ke basis data Anda, itu hanyalah masalah memulihkan dari cadangan (lihat poin 4) dan mengubah pengguna basis data.
  4. Anda sering cadangan. Sering menjadi istilah relatif: jika Anda memposting 20 artikel setiap hari, Anda lebih baik membuat cadangan setiap hari atau setiap beberapa hari. Jika Anda memposting sekali seminggu, mencadangkan seminggu sekali kemungkinan sudah cukup.
  5. Anda memiliki situs Anda di bawah kontrol versi ( seperti ini ), yang berarti bahkan jika penyerang memperoleh akses, Anda dapat dengan mudah mendeteksi perubahan kode dan mengembalikannya. Jika penyerang memiliki akses ke wp-config, mereka mungkin mengacaukan sesuatu yang lain.
  6. Informasi basis data benar-benar satu-satunya hal yang sensitif wp-config, dan karena Anda berhati-hati tentang hal itu (lihat poin 3 dan 4), itu bukan masalah besar. Garam dan semacamnya dapat diubah kapan saja. Satu-satunya hal yang terjadi adalah ia membatalkan cookie pengguna yang masuk.

Bagi saya, wp-configkeluar dari root dokumen berbau keamanan oleh ketidakjelasan - yang sangat banyak.

chrisguitarguy
sumber
2
Ya, itulah yang saya pikirkan. Saya senang mengetahui bahwa saya bukan satu-satunya :) Saya ingin membiarkan pertanyaan terbuka untuk satu atau dua hari lagi kalau-kalau ada yang punya argumen kontra yang menarik, tapi sejauh ini sepertinya ini jawaban yang tepat untuk saya.
Ian Dunn
3
Koreksi kecil: Tidak ada manfaat keamanan untuk memindahkan file wp-config.php dari root dokumen. Ada manfaat lain, yang tidak terkait keamanan, dan yang hanya berlaku untuk pengaturan yang tidak biasa.
Otto
4
Hanya untuk menghilangkan mitos yang mungkin - apakah tidak mungkin, ada yang salah di sisi server - dalam hal ini kode php dicetak ke layar?
Stephen Harris
3
@IanDunn Tetapi jawaban terbaik menyarankan untuk memindahkannya keluar dari hierarki itu menjadi yang terpisah, yang tidak mengatasi masalah Anda tentang log dll. Jawaban ini tidak menjawab judul pertanyaan Anda "bergerak ... benar-benar bermanfaat", katanya. langkah-langkah keamanan lainnya bermanfaat, dan mencoba meyakinkan Anda untuk tidak khawatir tentang keamanan. Semua orang berpikir rumah mereka aman sampai mereka dirampok. Setelah itu mereka melakukan pekerjaan yang lebih baik. Beberapa orang tidak pernah dicuri, meskipun keamanan mereka rendah, tetapi itu tidak berarti itu saran yang baik untuk memiliki keamanan yang lebih rendah.
AndrewC
4
Ini adalah poin yang bagus, tetapi masalah terbesar saya adalah bahwa ini adalah argumen perbaikan, bukan argumen preventif. Sebagian besar dari ini berbicara tentang bagaimana itu bukan masalah besar karena A) Anda menganggap seseorang menangani pengguna db dengan benar dan B) Anda memiliki cadangan. Apa yang terjadi ketika Anda menggunakan sesuatu seperti woocommerce atau menyimpan informasi sensitif dalam database Anda? Maka Anda kacau.
Goldentoa11
25

Saya pikir Max adalah jawaban yang luas, dan itulah satu sisi dari cerita. The WordPress Codex memiliki lebih menyarankan :

Juga, pastikan bahwa hanya Anda (dan server web) yang dapat membaca file ini (umumnya berarti 400 atau 440 izin).

Jika Anda menggunakan server dengan .htaccess, Anda dapat meletakkan ini di file itu (di bagian paling atas) untuk menolak akses ke siapa pun yang berselancar untuknya:

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

Perhatikan bahwa pengaturan 400 atau 440 izin pada wp-config.php dapat mencegah plugin menulis atau memodifikasinya. Contoh asli adalah caching plugins (W3 Total Cache, WP Super Cache, dll.) Dalam hal ini, saya akan menggunakan 600 (izin default untuk file dalam /home/userdirektori).

ini aku
sumber
5
Max adalah jawabannya. +1 untuknya. Saya hanya berusaha memperpanjangnya.
its_me
1
Aahan Krish, Anda telah memukul mata banteng. Terima kasih untuk tambahannya.
Max Yudin
Jadi jika Anda menggunakan htaccess untuk menolak permintaan HTTP ke wp-config.php, bukankah itu mencapai hasil yang sama dengan memindahkannya di luar root dokumen, tetapi tanpa mengekspos log / backup / etc?
Ian Dunn
4
@IanDunn Tergantung pada apa root dokumen itu— (1) Jika wordpress di-host di direktori public_html, pindah ke wp-config.phpluar direktori berarti bahwa itu akan berada di public_htmldirektori. Dalam hal ini, Anda harus menggunakan aturan htaccess untuk menolak permintaan HTTP ke wp-config.php. (2) Jika WordPress diinstal langsung di bawah public_htmldirektori, satu tingkat naik => Anda akan memindahkannya ke /home/userdirektori. Dalam hal ini Anda cukup aman karena file tersebut berada di luar root dokumen. Anda masih dapat mengatur izin file menjadi 600 (atau bahkan lebih ketat 440 atau 400).
its_me
@IanDunn Seperti yang saya katakan, ini adalah pemahaman dasar saya, dan saya bukan ahli keamanan. :)
its_me
17

Seseorang meminta kami untuk bersinar, dan saya akan menjawab di sini.

Ya, ada manfaat keamanan dari mengisolasi wp-config.php Anda dari direktori root situs Anda.

1- Jika handler PHP Anda rusak atau diubah dengan cara tertentu, informasi DB Anda tidak akan diekspos. Dan ya, saya melihat ini terjadi beberapa kali pada host bersama selama pembaruan server. Ya, situs akan rusak selama periode itu, tetapi kata sandi Anda akan tetap utuh.

2- Praktik terbaik selalu merekomendasikan mengisolasi file konfigurasi dari file data. Ya, sulit untuk melakukannya dengan WordPress (atau aplikasi web apa pun), tetapi memindahkannya sedikit terisolasi.

3 - Ingat kerentanan PHP-CGI, di mana siapa pun bisa meneruskan? -S ke file dan melihat sumbernya. http://www.kb.cert.org/vuls/id/520827

Pada akhirnya, itu adalah detail kecil, tetapi mereka memang membantu meminimalkan risiko. Khususnya jika Anda berada di lingkungan bersama, di mana siapa pun dapat mengakses database Anda (yang mereka butuhkan adalah pengguna / pass).

Tapi jangan biarkan gangguan kecil (optimasi prematur) terjadi di depan apa yang benar-benar diperlukan untuk mendapatkan situs dengan benar:

1- Selalu perbarui

2- Gunakan kata sandi yang kuat

3- Batasi akses (melalui izin). Kami punya posting tentang itu di sini:

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

Terima kasih,

Sucuri
sumber
Hai teman-teman, terima kasih telah menambahkan pemikiran Anda. Saya pikir kita sudah menyentuh sebagian besar poin di jawaban lain dan komentar mereka. 1) Ya, ini mungkin, tetapi jarang; 2) Ya, ini memiliki manfaat, tetapi minimal; 3) Ya, ini mungkin, tetapi jenis kerentanan seperti itu tidak mungkin terjadi lagi, dan melindunginya seperti bermain whac-a-mole, atau membuat orang melepas sepatu di bandara karena beberapa bajingan menyembunyikan bom di rumahnya sepatu sekali. Ini reaksioner dan tidak mungkin memiliki manfaat masa depan.
Ian Dunn
Dalam berbagai diskusi, pertanyaan disaring dari "Apakah ada manfaatnya?" untuk "Ok, ada beberapa manfaat, tetapi apakah mereka lebih besar daripada risikonya?" Risiko utama yang saya maksudkan adalah kenyataan bahwa Anda harus memperluas cakupan openbase_dir untuk membiarkan skrip akses PHP di luar web root. Banyak pengaturan hosting - termasuk yang menggunakan Plesk, yang banyak - menyimpan log, cadangan, area FTP pribadi yang seharusnya diisolasi dari root web, dll dalam direktori di atas root web. Jadi, memberikan akses PHP ke direktori itu bisa menjadi kerentanan serius.
Ian Dunn
15

Pasti ya.

Ketika Anda memindahkan wp-config.php di luar direktori publik, Anda melindunginya dari membaca menggunakan browser ketika php handler berubah menjadi berbahaya (atau tidak sengaja!).

Membaca login / kata sandi DB Anda dimungkinkan ketika server hampir tidak terinfeksi melalui kesalahan administrator lumpuh. Isi denda administrator dan dapatkan host server yang cenderung lebih baik dan lebih dapat diandalkan. Padahal itu mungkin lebih mahal.

Max Yudin
sumber
4
Jika penyerang memiliki akses yang cukup untuk mengubah handler PHP, Anda sudah kacau. Perubahan yang tidak disengaja sangat langka dalam pengalaman saya, dan dalam hal ini akan mudah untuk mengubah kata sandi. Mengingat hal-hal itu, apakah Anda masih berpikir itu sepadan dengan risiko mengekspos log / backup / etc karena open_basedirruang lingkup diperluas ?
Ian Dunn
1
Saya tidak pernah memiliki -rwxakses ke direktori yang lebih tinggi dari itu public_htmlsehingga saya tidak pernah terbiasa dengannya open_basedir. Log saya berada di direktori yang terpisah, demikian juga cadangan. Saya pikir itulah yang dimiliki semua host bersama.
Max Yudin
Host sangat bervariasi; tidak ada struktur direktori standar. Plesk (salah satu panel kontrol paling populer untuk host bersama) meletakkan log di /var/www/vhosts/example.com/statistics/logs dan root dokumen adalah /var/www/vhosts/example.com/httpdocs. Memindahkan wp-config.php ke /var/www/vhosts/example.com/wp-config.php akan membutuhkan pemberian akses skrip ke seluruh direktori example.com.
Ian Dunn
Hanya ingin tahu, di mana log dan cadangan Anda disimpan, jika tidak di direktori domain? Apakah mereka diakses melalui panel kontrol atau sesuatu?
Ian Dunn
1
Ya, melalui panel kontrol.
Max Yudin
8

Saya hanya ingin mengklarifikasi, demi argumen, bahwa memindahkan file wp_config.php Anda tidak selalu berarti Anda harus memindahkannya hanya ke direktori induk. Katakanlah Anda memiliki struktur seperti / root / html, di mana html berisi instalasi WP dan semua konten HTML Anda. Alih-alih memindahkan wp_config.php ke / root, Anda bisa memindahkannya ke sesuatu seperti / root / secure ... yang keduanya di luar direktori html dan juga tidak di direktori root server. Tentu saja, Anda perlu memastikan bahwa php dapat berjalan di folder aman ini juga.

Karena WP tidak dapat dikonfigurasi untuk mencari wp_config.php di folder saudara seperti / root / secure, Anda harus mengambil langkah tambahan. Saya meninggalkan wp_config.php di / root / html, dan memotong bagian sensitif (login database, garam, awalan tabel) dan memindahkannya ke file terpisah yang disebut config.php. Kemudian Anda menambahkan includeperintah PHP ke wp_config.php Anda, seperti ini:include('/home/content/path/to/root/secure/config.php');

Ini pada dasarnya adalah apa yang telah saya lakukan dalam pengaturan saya. Sekarang, berdasarkan diskusi di atas, saya masih mengevaluasi apakah itu perlu atau bahkan ide yang bagus. Tetapi saya hanya ingin menambahkan bahwa konfigurasi di atas dimungkinkan. Itu tidak mengekspos cadangan Anda dan file root lainnya, dan selama folder aman tidak diatur dengan URL publiknya sendiri, itu tidak dapat dijelajahi.

Selain itu, Anda dapat membatasi akses ke folder aman dengan membuat file .htaccess di sana dengan:

order deny,allow
deny from all
allow from 127.0.0.1
Michael
sumber
Hei Michael, terima kasih sudah berbagi itu. Apakah Anda sudah mencobanya di lingkungan nyata untuk memverifikasi itu berhasil? Saya pikir open_basedirdirektif mengambil seluruh pohon , sehingga untuk mengakses /root/securedari /root/html, Anda harus mengatur open_basedirke /root.
Ian Dunn
Untuk membuat ide Anda berfungsi, saya pikir Anda perlu mengatur struktur direktori seperti /root/httpdocs/config/accessible, tempat httpdocsmenyimpan log, cadangan, dll; configmemegang wp-config.php, dan accessiblemenyimpan WordPress serta semua konten. Anda harus memodifikasi konfigurasi vhost, dll untuk memetakan kembali root dokumen accessible. Saya tidak melihat manfaat apa pun selain hanya menolak permintaan HTTP ke wp-config di pengaturan default.
Ian Dunn
1
Menurut php.net/manual/en/ini.core.php#ini.open-basedir : "Di bawah Windows, pisahkan direktori dengan titik koma. Pada semua sistem lain, pisahkan direktori dengan titik dua. Sebagai modul Apache, path open_basedir dari direktori induk sekarang secara otomatis diwarisi. " Jadi Anda dapat mengatur beberapa direktori, tidak perlu direktori berada dalam satu pohon.
Michael
Saya baru saja menguji itu dan sepertinya Anda benar. Saya masih tidak yakin apa manfaat keamanan ini lebih dari sekadar menolak akses ke file melalui Apache.
Ian Dunn
@IanDunn berbicara dengan baik dalam jawaban Aaron Adams
AndrewC
4

Ada banyak tema dan plugin yang ditulis dengan buruk di luar sana yang memungkinkan atatckers untuk menyuntikkan kode (ingat masalah keamanan dengan Timthumb). Jika saya akan menjadi seorang penyerang, mengapa saya harus mencari wp-config.php? Cukup menyuntikkan kode ini:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Anda dapat mencoba menyembunyikan wp-config.php Anda. Selama WordPress membuat semua informasi sensitif dapat diakses secara global, tidak ada untungnya menyembunyikan wp-config.php.

Bagian buruk di wp-config.php bukanlah ia menyimpan data sensitif. Bagian yang buruk adalah mendefinisikan data sensitif sebagai konstanta yang dapat diakses secara global.

Memperbarui

Saya ingin menjelaskan masalah dengan define()dan mengapa itu adalah ide yang buruk untuk mendefinisikan data sensitif sebagai konstanta global.

Ada banyak cara untuk menyerang situs web. Injeksi skrip hanya satu cara untuk menyerang situs web.

Dengan asumsi server memiliki kerentanan yang memungkinkan penyerang mengakses dump memori. Penyerang akan menemukan di memori dump semua nilai semua variabel. Jika Anda menetapkan konstanta yang dapat diakses secara global, ia harus tetap dalam memori hingga skrip berakhir. Membuat variabel alih-alih konstanta, ada kemungkinan besar bahwa pemulung akan menimpa (atau membebaskan) memori setelah variabel tidak lagi diperlukan.

Cara yang lebih baik untuk melindungi data sensitif adalah menghapusnya segera setelah menggunakannya:

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

Setelah menggunakan data sensitif, penugasan nullakan menimpa data dalam memori. Seorang penyerang harus mendapatkan memori dump tepat pada saat ketika $db_conberisi data sensitif. Dan itu adalah waktu yang sangat singkat dalam contoh di atas (jika kelas Database_Handler tidak menyimpan salinannya).

Ralf912
sumber
Tanggapan ini tidak secara langsung menjawab pertanyaan. Setiap pengaya plugin dapat memiliki hari lapangan dengan WordPress jika mereka meyakinkan Anda untuk menginstal kode mereka dan memiliki niat jahat. Itu tidak berbeda dengan rela memasang virus di sistem Anda. Argumen ini untuk tidak memindahkan wp-config.php tidak ada gunanya. Ini seperti mengatakan bahwa dengan sengaja memasang bom mobil di mobil Anda membuat pengaturan alarm mobil tidak berguna. Secara teknis benar tetapi WTF?!?
Lance Cleveland
2
Tidak, ini tidak ada gunanya. Pertanyaannya adalah: Dapatkah saya melindungi akun basis data dengan menyembunyikan wp-config.php. Dan jawabannya jelas: Tidak. Itu sama dengan jika Anda bertanya, "Bisakah saya melindungi mobil saya dari bom mobil dengan alarm mobil?" Tidak ada manfaat lain dengan menyembunyikan wp-config Anda untuk melindungi akses basis data atau akses ftp. Keduanya berada dalam lingkup global. Saya yakin ada lebih banyak cara bagi penyerang untuk mendapatkan akses ke vars global tanpa menyuntikkan kode.
Ralf912
Saya tidak melihat "dapatkah saya melindungi akun basis data dengan menyembunyikan wp-config.php" di pertanyaan awal. Pertanyaan aslinya adalah "apakah masuk akal untuk memindahkan wp-config.php". Jawabannya benar-benar ya, IMO. Ini seperti menanyakan apakah Anda harus mengunci pintu depan saat keluar. Mengatakan "seseorang dapat dengan mudah memecahkan jendela dan tetap masuk, jadi mengapa repot" tidak menjawab poin mendasar dari pertanyaan. IMO pertanyaan yang diajukan adalah ini, "Apakah sepadan dengan usaha ekstra untuk memindahkan wp-config.php? APA MANFAAT yang melakukan itu?". Iya. Paling tidak itu mencegah para peretas malas.
Lance Cleveland
2
Salah satu praktik terbaik keamanan paling umum ... Anda melewatkan satu poin yang sangat (sangat, sangat) penting: Untuk apa penyerang tertarik? Dan itu bukan bagaimana Anda menata wp-config.php Anda. Seorang penyerang terputus dalam nilai yang Anda tentukan di wp-config Anda. Meraih contoh Anda dengan pintu depan: Menyembunyikan konfigurasi wp Anda sama seperti jika Anda akan mengunci pintu depan Anda, tetapi simpan semua emas Anda tanpa perlindungan di taman. Semua nilai yang didefinisikan dalam konfigurasi wp didefinisikan secara global . Jadi mereka semua dapat diakses di luar wp-config. Bahkan jika Anda menyembunyikan konfigurasi wp Anda, nilainya tetap ada.
Ralf912
1
Saya pikir orang-orang yang berpendapat mendukung pemindahan itu mencoba melindungi terhadap skenario di mana wp-config.php dapat ditampilkan dalam teks biasa melalui permintaan HTTP, daripada skenario di mana ia dapat diekspos ke kode PHP lain yang berjalan di host.
Ian Dunn
-1

Terlepas dari manfaat keamanan, itu juga memungkinkan Anda untuk menyimpan contoh WordPress Anda di bawah kontrol versi sambil menjaga file inti WordPress sebagai submodule / eksternal. Ini adalah bagaimana Mark Jaquith mengatur proyek WordPress-Skeleton-nya. Lihat https://github.com/markjaquith/WordPress-Skeleton#assumptions untuk detailnya.

Emzo
sumber
8
Ia mengaturnya di root dokumen, bukan di luarnya, jadi tidak relevan dengan pertanyaan ini. Teknik yang ditanyakan oleh pertanyaan menentukan bahwa Anda memindahkan wp-config.phpsatu direktori di atas root dokumen vhost , bukan hanya satu direktori di atas folder instalasi WordPress. Intinya adalah untuk mendapatkannya di luar folder yang dapat dibaca oleh permintaan HTTP.
Ian Dunn