135

सबसे आम सुरक्षा सर्वोत्तम प्रथाओं में से एक इन दिनों एक निर्देशिका vhost के दस्तावेज़ रूट की तुलना में अधिक बढ़ रहा हैwp-config.php । मैंने वास्तव में उसके लिए एक अच्छा स्पष्टीकरण नहीं पाया है, लेकिन मैं यह मान रहा हूं कि वेबरूट के भीतर डेटाबेस पासवर्ड पढ़ने से दुर्भावनापूर्ण या संक्रमित स्क्रिप्ट के जोखिम को कम करना है।

लेकिन, आपको अभी भी वर्डप्रेस को एक्सेस करने देना है, इसलिए आपको open_basedirडॉक्यूमेंट रूट के ऊपर डायरेक्टरी को शामिल करने के लिए विस्तार करना होगा। क्या यह पूरे उद्देश्य को नहीं हराता है, और संभावित रूप से हमलावरों को सर्वर लॉग, बैकअप आदि को भी उजागर करता है?

या तकनीक केवल एक स्थिति को रोकने की कोशिश कर रही है जहां PHP इंजन द्वारा पार्स किए जाने के बजाय, wp-config.phpअनुरोध करने वाले किसी व्यक्ति को सादे-पाठ के रूप में दिखाया जाएगा http://example.com/wp-config.php? यह एक बहुत ही दुर्लभ घटना है, और यह HTTP अनुरोधों के लिए लॉग / बैकअप / आदि को उजागर करने के डाउनसाइड को आगे नहीं बढ़ाएगा।

शायद अन्य फ़ाइलों को उजागर किए बिना कुछ होस्टिंग सेटअप में दस्तावेज़ रूट के बाहर इसे स्थानांतरित करना संभव है, लेकिन अन्य सेटअप में नहीं?

निष्कर्ष: इस मुद्दे पर बहुत आगे-पीछे होने के बाद, दो उत्तर सामने आए हैं कि मुझे लगता है कि इसे आधिकारिक माना जाना चाहिए। हारून Adams wp-config, और chrisguitarguymakes को इसके खिलाफ एक अच्छा मामला बनाने के पक्ष में एक अच्छा मामला बनाता है । वे दो उत्तर हैं जिन्हें आपको पढ़ना चाहिए यदि आप थ्रेड के लिए नए हैं और पूरी बात नहीं पढ़ना चाहते हैं। अन्य उत्तर या तो बेमानी हैं या गलत हैं।

security customization wp-config

— इयान डन
स्रोत

यह वास्तव में आवश्यक नहीं है कि आप अपनी पसंद का जवाब दें और अन्य सभी उत्तरों को अस्वीकार कर दें, अपने प्रश्न के अंदर। जैसा कि आप नीचे देख सकते हैं, कि स्टैकएक्सचेंज वोटिंग सिस्टम क्या है, लोगों को समझ में आने वाले उत्तरों को वोट करने के लिए, जबकि प्रश्न पूछने वालों को "स्वीकृत उत्तर" तंत्र और अपने स्वयं के अप / डाउन वोट का उपयोग करना चाहिए।

— कजकाई

6

मैंने ऐसा नहीं किया है कि 99% प्रश्न मैंने पूछे हैं, लेकिन मुझे लगा कि यह इस विशिष्ट मामले में उचित था। प्रश्न के 8 उत्तर हैं, जिनमें से कुछ काफी लम्बे / जटिल हैं, और जिनमें से कुछ में गलत जानकारी होने या बातचीत में कुछ भी न जोड़ने के बावजूद बहुत अधिक उत्थान हैं। मुझे लगता है कि पहली बार धागा पढ़ने वाले लोगों के लिए एक अर्ध-आधिकारिक निष्कर्ष प्रदान करना मददगार है। हमेशा की तरह, पाठक अपने मन बनाने के लिए स्वतंत्र हैं; मैं सिर्फ ओपी के रूप में अपनी राय दे रहा हूं।

— इयान दून

1

@Kzqai: "स्टेक्सएक्सचेंज वोटिंग सिस्टम" एक लोकतांत्रिक प्रक्रिया है, और प्रतिभागी अक्सर 1) स्पष्ट नहीं करते हैं कि ओपी वास्तव में क्या पूछ रहा है या हल करने की कोशिश कर रहा है, और 2) किसी विशेष उत्तर की वैधता की सीधी व्याख्या नहीं कर रहा है। प्रतिक्रियाओं में छलाँग लगने के बाद और वोट डाले गए हैं, यह ओपी के उन जवाबों को स्पष्ट करने में मददगार है जो सहायता प्रदान करते हैं। आखिरकार, ओपी केवल एक ही है जो जानता है, और मैं चाहता हूं कि ओपी ने ऐसा किया। हां, लोग "उन उत्तरों को वोट देते हैं जो लोगों को समझ में आते हैं," लेकिन चलो ओपी के पास आखिरी शब्द है जो उसके लिए समझ में आता है।

— मैक

127

संक्षिप्त उत्तर: हाँ

इस सवाल का जवाब एक अस्वाभाविक हाँ है , और अन्यथा पूरी तरह से गैर जिम्मेदाराना है ।

दीर्घ उत्तर: एक वास्तविक दुनिया का उदाहरण

मुझे अपने वास्तविक सर्वर से बहुत वास्तविक उदाहरण प्रदान करने की अनुमति दें, जहां wp-config.phpवेब रूट के बाहर जाने से विशेष रूप से इसकी सामग्री को कैप्चर होने से रोका जा सके ।

बग:

Plesk में एक बग के इस विवरण पर एक नज़र डालें (11.0.9 MU # 27 में तय):

होस्टिंग योजना के साथ सदस्यता को समन्वयित करने के बाद Plesk ने उप-डोमेन अग्रेषित किया (117199)

हानिरहित लगता है, है ना?

खैर, यहाँ मैंने इस बग को ट्रिगर करने के लिए क्या किया है:

अन्य URL पर रीडायरेक्ट करने के लिए (उदाहरण के लिए एक उप डोमेन सेट अप site.staging.server.comकरने के लिए site-staging.ssl.server.com)।
सदस्यता की सेवा योजना (जैसे इसके PHP विन्यास) को बदल दिया।

जब मैंने ऐसा किया, तो Plesk ने उपडोमेन को डिफॉल्ट करने के लिए रीसेट कर दिया: ~/httpdocs/बिना किसी व्याख्याकार (जैसे PHP) के सक्रिय के साथ सामग्री की सेवा ।

और मैंने ध्यान नहीं दिया। हफते के लिए।

परिणाम:

साथ wp-config.phpवेब जड़ में, एक अनुरोध के /wp-config.phpवर्डप्रेस विन्यास फाइल डाउनलोड किया जाएगा।
साथ wp-config.phpवेब जड़ के बाहर, एक अनुरोध के /wp-config.phpएक पूरी तरह से हानिरहित फ़ाइल डाउनलोड की। असली wp-config.phpफ़ाइल डाउनलोड नहीं की जा सकी।

इस प्रकार, यह स्पष्ट है कि wp-config.phpवेब रूट के बाहर जाने से वास्तविक दुनिया में सुरक्षा संबंधी लाभ होते हैं ।

`wp-config.php`अपने सर्वर पर किसी भी स्थान पर कैसे जाएं

वर्डप्रेस स्वचालित रूप से आपकी wp-config.phpफ़ाइल के लिए आपके वर्डप्रेस इंस्टॉलेशन के ऊपर एक निर्देशिका को देखेगा , इसलिए यदि आपने इसे स्थानांतरित कर दिया है, तो आप कर रहे हैं!

लेकिन क्या होगा अगर आपने इसे कहीं और स्थानांतरित कर दिया है? आसान। wp-config.phpनिम्नलिखित कोड के साथ वर्डप्रेस निर्देशिका में एक नया बनाएँ :

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

(अपनी स्थानांतरित wp-config.phpफ़ाइल के वास्तविक पथ के लिए उपरोक्त पथ को बदलना सुनिश्चित करें ।)

यदि आप किसी समस्या में भाग लेते हैं open_basedir, तो open_basedirअपने PHP कॉन्फ़िगरेशन में निर्देश के लिए नया पथ जोड़ें :

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

बस!

इसके विपरीत तर्क देना

wp-config.phpवेब रूट के बाहर जाने के खिलाफ हर तर्क गलत धारणाओं पर टिका है।

तर्क 1: यदि PHP अक्षम है, तो वे पहले से ही अंदर हैं

जिस तरह से किसी को यह देखने के लिए जा रहा है कि सामग्री [ wp-config.php] है अगर वे आपके सर्वर को PHP दुभाषिया को दरकिनार करते हैं ... यदि ऐसा होता है, तो आप पहले से ही परेशानी में हैं: उनके पास आपके सर्वर तक सीधी पहुंच है।

FALSE : मैं जिस परिदृश्य का वर्णन करता हूं, वह एक गलत धारणा का परिणाम है, न कि घुसपैठ का।

तर्क 2: गलती से PHP को अक्षम करना दुर्लभ है, और इसलिए महत्वहीन है

यदि किसी हमलावर के पास PHP हैंडलर बदलने के लिए पर्याप्त पहुंच है, तो आप पहले से ही खराब हैं। मेरे अनुभव में आकस्मिक परिवर्तन बहुत कम हैं, और उस स्थिति में पासवर्ड बदलना आसान होगा।

FALSE : मैं जिस परिदृश्य का वर्णन करता हूं, वह सर्वर सॉफ़्टवेयर के एक सामान्य टुकड़े में बग का परिणाम है, जो एक सामान्य सर्वर कॉन्फ़िगरेशन को प्रभावित करता है। यह शायद ही "दुर्लभ" है (और इसके अलावा, सुरक्षा का मतलब दुर्लभ परिदृश्य के बारे में चिंता करना है)।

डब्ल्यूटीएफ : घुसपैठ के बाद पासवर्ड बदलना मुश्किल से मदद करता है अगर घुसपैठ के दौरान संवेदनशील जानकारी को उठाया गया था। वास्तव में, क्या हम अभी भी सोचते हैं कि वर्डप्रेस का उपयोग केवल आकस्मिक ब्लॉगिंग के लिए किया जाता है, और यह कि हमलावर केवल बचाव में रुचि रखते हैं? चलो हमारे सर्वर की रक्षा के बारे में चिंता करें, न कि किसी के अंदर जाने के बाद इसे बहाल करना।

तर्क 3: पहुंच से इनकार करना `wp-config.php`काफी अच्छा है

आप अपने वर्चुअल होस्ट कॉन्फिग के माध्यम से फ़ाइल तक पहुंच को प्रतिबंधित कर सकते हैं या .htaccess- प्रभावी ढंग से फ़ाइल के बाहर पहुंच को उसी तरह सीमित कर सकते हैं जैसे कि दस्तावेज़ के बाहर ले जाना।

FALSE : कल्पना करें कि वर्चुअल होस्ट के लिए आपके सर्वर डिफॉल्ट हैं: कोई PHP, नहीं .htaccess, allow from all(उत्पादन वातावरण में शायद ही असामान्य)। यदि आपका कॉन्फ़िगरेशन किसी रूटीन ऑपरेशन के दौरान किसी तरह रीसेट हो जाता है - जैसे, कहो, एक पैनल अपडेट - सब कुछ अपनी डिफ़ॉल्ट स्थिति में वापस आ जाएगा, और आप उजागर होंगे।

यदि आपका सुरक्षा मॉडल विफल हो जाता है जब सेटिंग्स गलती से डिफ़ॉल्ट पर रीसेट हो जाती हैं, तो आपको अधिक सुरक्षा की आवश्यकता होती है।

डब्ल्यूटीएफ : कोई भी विशेष रूप से सुरक्षा की कम परतों की सिफारिश क्यों करेगा? महंगी कारों में सिर्फ ताले नहीं होते; उनके पास अलार्म, इमोबिलाइज़र और जीपीएस ट्रैकर्स भी हैं। अगर किसी चीज की कीमत बचती है, तो उसे सही करें।

तर्क 4: अनधिकृत पहुंच `wp-config.php`कोई बड़ी बात नहीं है

डेटाबेस जानकारी वास्तव में [ wp-config.php] में एकमात्र संवेदनशील सामान है ।

FALSE : प्रमाणीकरण कुंजी और लवण का उपयोग किसी भी संभावित अपहरण हमलों में किया जा सकता है।

डब्ल्यूटीएफ : यहां तक कि अगर डेटाबेस क्रेडेंशियल केवल एक चीज थी wp-config.php, तो आपको एक हमलावर को उन पर अपना हाथ पाने से डरना चाहिए ।

तर्क 5: `wp-config.php`वेब रूट के बाहर जाने से वास्तव में सर्वर कम सुरक्षित हो जाता है

आपको अभी भी वर्डप्रेस का उपयोग करना है [ wp-config.php], इसलिए आपको open_basedirदस्तावेज़ रूट के ऊपर निर्देशिका को शामिल करने के लिए विस्तार करने की आवश्यकता है ।

FALSE : मान लिया गया wp-config.phpहै httpdocs/, बस इसे स्थानांतरित करने के लिए ../phpdocs/, और open_basedirकेवल httpdocs/और शामिल करने के लिए सेट करें phpdocs/। उदाहरण के लिए:

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

( यदि आपके पास एक है, तो हमेशा याद रखें /tmp/या अपनी उपयोगकर्ता tmp/निर्देशिका शामिल करें ।)

निष्कर्ष: विन्यास फाइल हमेशा हमेशा चाहिए हमेशा वेब जड़ के बाहर स्थित हो

यदि आप सुरक्षा की परवाह करते हैं, तो आप wp-config.phpअपनी वेब रूट से बाहर चले जाएंगे ।

— हारून एडम्स
स्रोत

1

यदि आपके पास अपाचे, लिनक्स या व्यवस्थापक के दिमाग में बग है, तो आप किसी भी मामले में एक टोस्ट हैं। आपके परिदृश्य में आप यह समझाने में विफल रहते हैं कि वेब साइट के रूट पर तब सर्वर पर किसी अन्य स्थान पर ग़लतफ़हमी होने की अधिक संभावना क्यों है। एक गलत तरीके से किया गया अपाचे शायद /../config.php तक पहुंच सकता है /config.php जितना आसान होगा

— मार्क

1

आप "किसी भी मामले में टोस्ट नहीं हैं।" यह बहुत संभावित है , और यहां तक कि प्रदर्शनकारी भी , कि बग के परिणामस्वरूप वेब रूट को उसके डिफ़ॉल्ट पर रीसेट किया जाएगा, जिस स्थिति में आप "टोस्ट" नहीं हैं - आपका wp-config.phpअवशेष सुरक्षित है। और यह बेहद असंभव है - इतना अनिवार्य रूप से असंभव होने के लिए इतना - कि बग के परिणामस्वरूप वेब रूट मनमाने ढंग से उस सटीक निर्देशिका में रीसेट हो जाएगा जिसमें आपने अपना स्थान रखा था wp-config.php।

— आरोन एडम्स

1

@IanDunn वास्तव में, wp-config.phpकिसी अनियंत्रित स्थान पर जाना आसान है । मैंने अपने उत्तर में दिशाएँ जोड़ दी हैं; इसमें सिर्फ wp-config.phpवर्डप्रेस डायरेक्टरी में डमी बनाना शामिल है जो वास्तविक के स्थान को संदर्भित करता है।

— हारून एडम्स

3

यह प्रतिक्रिया स्पॉट-ऑन है। मेरी वेब होस्टिंग कंपनी को ड्राइव सरणी विफलता थी। जब सब कहा और किया गया था तो उन्होंने प्रणाली को विशेष रूप से बहाल किया। पता चला कि उन्होंने httpd.conf फ़ाइलों को फिर से बनाने के लिए cPanel / WHM स्क्रिप्ट की एक श्रृंखला का उपयोग किया था जो कि गलत तरीके से किया था। सौभाग्य से मैं पहले से ही doc रूट के बाहर wp-config.php था, लेकिन अगर मेरे पास सामग्री नहीं थी तो लेने के लिए नहीं थी। हां दुर्लभ, लेकिन जैसा कि विरल मामलों में उल्लेख किया गया है कि आपको किस बारे में चिंता करने की आवश्यकता है। इसके अलावा, "सरल दिमाग वाले लोक खो जाएंगे" बताते हुए LESS सुरक्षा के लिए एक बुरा बहाना है।

— लांस क्लीवलैंड

1

यह एक अच्छी बात है, हारून। मैं अभी भी इस और अन्य टिप्पणी धागा में वर्णित कारणों के लिए थोड़ा उलझन में हूं, लेकिन आपने मुझे आश्वस्त किया है कि मूल रूप से मैंने जितना सोचा था, उससे अधिक योग्यता है। बहुत कम से कम, अगर ठीक से किया जाए, तो मुझे नहीं लगता कि इससे कुछ भी होगा। मुझे अभी भी इस बात की समस्या है कि इसे बढ़ावा देने वाले अधिकांश लोग इसके कारणों को समझ नहीं पाते हैं, और जिस तरह से वे इसे सिखाते हैं वह अक्सर httpdocs के ऊपर की निर्देशिका को उजागर करेगा, लेकिन आपने उन मुद्दों को हल करने में मदद की है आपका उत्तर।

— इयान डन

40

सबसे बड़ी बात wp-config.phpइसमें कुछ संवेदनशील जानकारी है: आपका डेटाबेस उपयोगकर्ता नाम / पासवर्ड, आदि।

इसलिए विचार: इसे दस्तावेज़ रूट के बाहर ले जाएं, और आपको किसी भी चीज़ के बारे में चिंता करने की ज़रूरत नहीं है। एक हमलावर कभी भी उस फाइल को बाहरी स्रोत से एक्सेस नहीं कर पाएगा।

यहाँ रगड़ना है, हालांकि: wp-config.phpवास्तव में स्क्रीन के लिए कुछ भी प्रिंट नहीं करता है। यह केवल विभिन्न स्थिरांक को परिभाषित करता है जो आपके WP इंस्टॉल में उपयोग किए जाते हैं। इस प्रकार किसी को उस फ़ाइल की सामग्री को देखने का एकमात्र तरीका यह है कि क्या वे आपके सर्वर PHP दुभाषिया को दरकिनार करते हैं - उन्हें .phpसिर्फ सादे पाठ के रूप में प्रस्तुत करने के लिए फ़ाइल मिलती है । यदि ऐसा होता है, तो आप पहले से ही परेशानी में हैं: उनके पास आपके सर्वर (और शायद रूट अनुमतियां) तक सीधी पहुंच है और वे जो चाहें कर सकते हैं।

मैं आगे जा रहा हूं और कहता हूं कि सुरक्षा के दृष्टिकोण से दस्तावेज़ रूट के बाहर जाने का कोई लाभ नहीं wp-configहै - ऊपर दिए गए कारणों और इन के लिए:

आप अपने वर्चुअल होस्ट कॉन्फ़िगरेशन या .htaccess के माध्यम से फ़ाइल तक पहुंच को प्रतिबंधित कर सकते हैं - प्रभावी रूप से फ़ाइल तक पहुंच को उसी तरह सीमित कर सकते हैं जैसे कि दस्तावेज़ रूट के बाहर ले जाना।
आप सुनिश्चित कर सकते हैं कि फ़ाइल अनुमतियाँ wp-configSSH के माध्यम से आपके सर्वर तक पहुँच (सीमित) प्राप्त करने के बावजूद किसी भी उपयोगकर्ता को फ़ाइल को पढ़ने से पर्याप्त विशेषाधिकार के बिना रोकने के लिए सख्त हैं ।
आपकी संवेदनशील जानकारी, डेटाबेस सेटिंग्स, केवल एक ही साइट पर उपयोग की जाती हैं। यहां तक कि अगर कोई हमलावर उस जानकारी तक पहुंच प्राप्त करता है, तो यह प्रभावित करने वाली एकमात्र साइट वर्डप्रेस इंस्टॉल होगी जिसमें wp-config.phpफ़ाइल संबंधित है। इससे भी महत्वपूर्ण बात यह है कि उस डेटाबेस उपयोगकर्ता के पास केवल उस WP इंस्टॉल के डेटाबेस को पढ़ने और लिखने की अनुमति है और कुछ नहीं - अन्य उपयोगकर्ताओं को अनुमति देने के लिए कोई एक्सेस नहीं। मतलब, दूसरे पासवर्ड में, यदि कोई हमलावर आपके डेटाबेस तक पहुँच प्राप्त करता है, तो यह बस बैकअप से बहाल करने की बात है (बिंदु 4 देखें) और डेटाबेस उपयोगकर्ता को बदलना
आप अक्सर बैकअप लेते हैं। अक्सर एक रिश्तेदार शब्द होने के नाते: यदि आप हर दिन 20 लेख पोस्ट करते हैं, तो आप हर दिन या हर कुछ दिनों में बेहतर बैकअप लेते हैं। यदि आप सप्ताह में एक बार पोस्ट करते हैं, तो सप्ताह में एक बार बैकअप लेना संभव है।
आपके पास संस्करण नियंत्रण ( जैसे ) के तहत आपकी साइट है , जिसका अर्थ है कि भले ही किसी हमलावर ने पहुंच प्राप्त की हो, आप आसानी से कोड परिवर्तनों का पता लगा सकते हैं और उन्हें वापस रोल कर सकते हैं। यदि किसी हमलावर के पास पहुंच है wp-config, तो उन्होंने शायद कुछ और गड़बड़ कर दी है।
डेटाबेस जानकारी वास्तव में केवल संवेदनशील सामान है wp-config, और क्योंकि आप इसके बारे में सावधान हैं (बिंदु 3 और 4 देखें), यह बहुत बड़ी बात नहीं है। साल्ट और ऐसे किसी भी समय बदला जा सकता है। केवल एक चीज यह होती है कि यह उपयोगकर्ताओं की कुकीज़ में लॉग इन को अमान्य करता है।

मेरे लिए, wp-configअस्पष्टता से सुरक्षा के दस्तावेज़ रूट रीच से बाहर निकलना - जो बहुत ही एक पुआल आदमी है।

— chrisguitarguy
स्रोत

2

हाँ, यह बहुत ज्यादा है जो मैं सोच रहा था। मुझे यह जानकर खुशी हुई कि मैं केवल एक ही नहीं हूं :) मैं एक या दो दिन के लिए प्रश्न को खुला छोड़ना चाहता हूं, अगर किसी के पास एक सम्मोहक प्रतिवाद है, लेकिन अभी तक यह सही उत्तर की तरह लगता है मुझे।

— इयान डन

3

मामूली सुधार: दस्तावेज़ रूट से wp-config.php फ़ाइल को स्थानांतरित करने का कोई सुरक्षा लाभ नहीं है । अन्य लाभ हैं, जो सुरक्षा से संबंधित नहीं हैं, और जो केवल असामान्य सेटअपों पर लागू होते हैं।

— ओट्टो

4

बस एक संभव मिथक डिबंक करने के लिए - क्या यह संभव नहीं है, कुछ गलत सर्वर साइड हो सकता है - किस स्थिति में स्क्रीन पर php कोड प्रिंट होता है?

— स्टीफन हैरिस

3

@IanDunn लेकिन सबसे अच्छा जवाब अधिवक्ता इसे उस पदानुक्रम से पूरी तरह से अलग करने की वकालत करते हैं, जो लॉग्स आदि के बारे में आपकी चिंता को दूर करता है। यह उत्तर आपके प्रश्न के शीर्षक का उत्तर नहीं देता है "चल रहा है ... वास्तव में फायदेमंद है", यह सिर्फ कहता है। अन्य सुरक्षा उपाय फायदेमंद हैं, और आपको सुरक्षा के बारे में चिंता न करने के लिए आश्वस्त करने का प्रयास करते हैं। हर कोई सोचता है कि उनका घर तब तक सुरक्षित रहे जब तक वे चोरी न कर लें। इसके बाद वे बेहतर काम करते हैं। कुछ लोग कभी भी परेशान नहीं होते, भले ही उनकी सुरक्षा कम हो, लेकिन इसका मतलब यह नहीं है कि कम सुरक्षा के लिए यह अच्छी सलाह है।

— एंड्रयूज

4

ये अच्छे बिंदु हैं, लेकिन इनके साथ मेरी सबसे बड़ी समस्या यह है कि ये उपचारात्मक तर्क हैं, निवारक तर्क नहीं हैं। इनमें से अधिकांश इस बारे में बात करते हैं कि यह बहुत बड़ी बात नहीं है क्योंकि A) आप मानते हैं कि किसी ने db उपयोगकर्ता को सही तरीके से संभाला है और B) आपके पास बैकअप है। जब आप woocommerce या अपने डेटाबेस में संवेदनशील जानकारी संग्रहीत करने जैसी किसी चीज़ का उपयोग कर रहे हों तो क्या होता है? फिर तुम बँधे हुए हो।

— गोल्डेंटोआ

25

मुझे लगता है कि मैक्स एक ज्ञानपूर्ण उत्तर है, और यह कहानी का एक पक्ष है। वर्डप्रेस कोडेक्स अधिक सलाह है :

इसके अलावा, सुनिश्चित करें कि केवल आप (और वेब सर्वर) इस फाइल को पढ़ सकते हैं (इसका आमतौर पर मतलब 400 या 440 अनुमति है)।

यदि आप .htaccess के साथ एक सर्वर का उपयोग करते हैं, तो आप इसे उस फ़ाइल में डाल सकते हैं (बहुत ऊपर) इसके लिए सर्फिंग करने वाले किसी भी व्यक्ति तक पहुँच से इनकार करने के लिए:
<files wp-config.php>
order allow,deny
deny from all
</files>

ध्यान दें कि wp-config.php पर 400 या 440 की अनुमति देना प्लगइन्स को लिखने या इसे संशोधित करने से रोक सकता है। उदाहरण के लिए एक वास्तविक मामला होगा, कैशिंग प्लगइन्स (W3 कुल कैश, WP सुपर कैश, आदि) उस मामले में, मैं 600 ( /home/userनिर्देशिका में फ़ाइलों के लिए डिफ़ॉल्ट अनुमति ) के साथ जाऊंगा ।

— यह मैं हूँ
स्रोत

5

मैक्स का जवाब है। उसे 1। मैं इसे विस्तार देने की कोशिश कर रहा हूं।

— its_me

1

अहान कृष, आपने बला की आंख मार ली है। जोड़ के लिए धन्यवाद।

— मैक्स युडिन

यदि आप HTTPacp को wp-config.php के अनुरोध से इनकार करने के लिए htaccess का उपयोग करते हैं, तो क्या यह परिणाम को दस्तावेज़ रूट के बाहर ले जाने के समान नहीं है, लेकिन लॉग / बैकअप / आदि को उजागर किए बिना?

— इयान डन

4

@IanDunn इस बात पर निर्भर करता है कि दस्तावेज़ रूट क्या है- (1) अगर वर्डप्रेस को किसी निर्देशिका में होस्ट किया जाता है public_html, wp-config.phpतो निर्देशिका से बाहर जाने का मतलब है कि यह public_htmlनिर्देशिका में होने वाला है । इस स्थिति में, आपको wp-config.php से HTTP अनुरोधों को अस्वीकार करने के लिए htaccess नियमों का उपयोग करना होगा। (2) यदि वर्डप्रेस public_htmlडायरेक्ट्री के तहत इंस्टॉल होता है , तो एक स्तर ऊपर => आप इसे /home/userडायरेक्ट्री में ले जाएंगे । इस मामले में आप बहुत सुरक्षित हैं क्योंकि फ़ाइल दस्तावेज़ रूट के बाहर है। आप अभी भी फ़ाइल की अनुमतियों को 600 (या यहां तक कि 440 या 400) पर सेट कर सकते हैं।

— इसके_मे

@IanDunn जैसा मैंने कहा, यह मेरी बुनियादी समझ है, और मैं कोई सुरक्षा विशेषज्ञ नहीं हूं। :)

— इसका_मे

17

किसी ने हमें अंदर चमकने के लिए कहा, और मैं यहां जवाब दूंगा।

हां, आपकी wp-config.php को आपकी साइट की रूट डायरेक्टरी से अलग करने से सुरक्षा लाभ हैं।

1- यदि आपका PHP हैंडलर किसी तरह से टूट या संशोधित हो जाता है, तो आपकी DB जानकारी उजागर नहीं होगी। और हां, मैंने सर्वर अपडेट के दौरान साझा किए गए मेजबानों पर ऐसा कुछ बार देखा। हां, उस दौरान साइट टूट जाएगी, लेकिन आपके पासवर्ड बरकरार रहेंगे।

2- सर्वश्रेष्ठ अभ्यास हमेशा डेटा फ़ाइलों से कॉन्फ़िगरेशन फ़ाइलों को अलग करने की सलाह देते हैं। हां, वर्डप्रेस (या किसी भी वेब ऐप) के साथ ऐसा करना मुश्किल है, लेकिन इसे ऊपर ले जाने से थोड़ा अलगाव होता है।

3- PHP-CGI भेद्यता को याद रखें, जहां कोई भी एक फ़ाइल में -s पास कर सकता है और स्रोत को देख सकता है। http://www.kb.cert.org/vuls/id/520827

अंत में, वे छोटे विवरण हैं, लेकिन वे जोखिम को कम करने में मदद करते हैं। विशेष रूप से यदि आप एक साझा वातावरण पर हैं, जहां कोई भी आपके डेटाबेस तक पहुंच सकता है (सभी की जरूरत है वह एक उपयोगकर्ता / पास है)।

लेकिन छोटे विकर्षणों (समय से पहले अनुकूलन) को सामने न आने दें जो किसी साइट को ठीक से सुरक्षित करने के लिए वास्तव में आवश्यक है:

1- इसे हमेशा अपडेट रखें

2- मजबूत पासवर्ड का उपयोग करें

3- पहुंच पर प्रतिबंध (अनुमतियों के माध्यम से)। हमारे पास इसके बारे में एक पोस्ट यहाँ है:

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

धन्यवाद,

— Sucuri
स्रोत

हे दोस्तों, अपने विचारों को जोड़ने के लिए धन्यवाद। मुझे लगता है कि हम पहले से ही उन दूसरे बिंदुओं और उनकी टिप्पणियों में से अधिकांश पर हिट करते हैं। 1) हाँ, यह संभव है, लेकिन दुर्लभ है; 2) हां, इसके लाभ हैं, लेकिन वे न्यूनतम हैं; 3) हां, यह संभव है, लेकिन उस प्रकार की भेद्यता फिर से होने की संभावना नहीं है, और इसके खिलाफ की रक्षा की तरह है जैसे whac-a-तिल खेलना, या लोगों को हवाई अड्डों पर अपने जूते निकालना क्योंकि कुछ jackass ने अपने में एक बम छिपाया था एक बार जूता। यह प्रतिक्रियात्मक है और भविष्य में लाभ होने की संभावना नहीं है।

— इयान डन

विभिन्न चर्चाओं में, इस प्रश्न को "क्या कोई लाभ है?" "ठीक है, कुछ फायदे हैं, लेकिन क्या वे जोखिमों से आगे निकल जाते हैं?" मुख्य जोखिम जिसका मैं जिक्र कर रहा हूं, वह यह है कि वेब रूट के बाहर पीएचपी की स्क्रिप्ट को जाने देने के लिए आपको ओपनबेस_डिअर दायरे का विस्तार करना होगा। कई होस्टिंग सेटअप - जिनमें वे भी शामिल हैं जो Plesk का उपयोग करते हैं, जो कि बहुत सारे हैं - स्टोर लॉग, बैकअप, निजी एफ़टीपी क्षेत्र जिन्हें वेब रूट से अलग किया जाना चाहिए, आदि वेब रूट के ऊपर की निर्देशिका में। तो, PHP को उस डायरेक्टरी में एक्सेस देना एक गंभीर जोखिम हो सकता है।

— इयान डन

15

निश्चित रूप से हाँ।

जब आप सार्वजनिक निर्देशिका के बाहर wp-config.php ले जाते हैं तो आप इसे ब्राउज़र का उपयोग करके पढ़ने से बचाते हैं जब php हैंडलर दुर्भावनापूर्ण रूप से (या गलती से!) बदल जाता है।

आपके DB लॉगिन / पासवर्ड को पढ़ना तब संभव है जब सर्वर को लंगड़ा व्यवस्थापक की गलती से संक्रमित किया जाता है। व्यवस्थापक को एक ठीक चार्ज करें और एक बेहतर-ट्रेंड और अधिक विश्वसनीय सर्वर होस्ट प्राप्त करें। हालांकि यह अधिक महंगा हो सकता है।

— मैक्स युडिन
स्रोत

4

यदि किसी हमलावर के पास PHP हैंडलर बदलने के लिए पर्याप्त पहुंच है, तो आप पहले से ही खराब हैं। मेरे अनुभव में आकस्मिक परिवर्तन बहुत कम हैं, और उस स्थिति में पासवर्ड बदलना आसान होगा। उन चीजों के प्रकाश में, क्या आपको अभी भी लगता है कि विस्तारित open_basedirदायरे के कारण लॉग / बैकअप / आदि को उजागर करने के जोखिम के लायक है ?

— इयान डन

1

मेरे पास कभी भी -rwxनिर्देशिकाओं तक पहुंच नहीं थी , public_htmlइसलिए मैं इससे परिचित नहीं था open_basedir। मेरे लॉग अलग निर्देशिका में हैं, इसलिए बैकअप करते हैं। मुझे लगता है कि सभी साझा मेजबान के पास यही है।

— मैक्स युडिन

मेजबान बेतहाशा भिन्न होते हैं; कोई मानक निर्देशिका संरचना नहीं है। Plesk (साझा मेजबानों के लिए सबसे लोकप्रिय कंट्रोल पैनल) /var/www/vhosts/example.com/statistics/logs में लॉग डालता है और दस्तावेज़ रूट /var/www/vhosts/example.com/httpdocs है। Wp-config.php को /var/www/vhosts/example.com/wp-config.php पर ले जाने के लिए संपूर्ण example.com निर्देशिका में स्क्रिप्ट एक्सेस देने की आवश्यकता होगी।

— इयान डन

जिज्ञासा से बाहर, आपके लॉग और बैकअप कहां संग्रहीत हैं, यदि डोमेन की निर्देशिका में नहीं हैं? क्या उन्हें एक नियंत्रण कक्ष या कुछ के माध्यम से पहुँचा जा सकता है?

— इयान दून

1

हाँ, एक नियंत्रण कक्ष के माध्यम से।

— मैक्स युडिन

8

मैं केवल स्पष्ट करना चाहता हूं, तर्क के लिए, कि आपकी wp_config.php फ़ाइल को स्थानांतरित करने का मतलब यह नहीं है कि आपको इसे केवल मूल निर्देशिका में स्थानांतरित करना है। मान लीजिए कि आपके पास / root / html जैसी संरचना है, जिसमें html में WP स्थापना और आपके सभी HTML सामग्री शामिल हैं। Wp_config.php को / root में ले जाने के बजाय, आप इसे कुछ इस तरह स्थानांतरित कर सकते हैं / root / safe ... जो html निर्देशिका के बाहर भी है और सर्वर रूट निर्देशिका में भी नहीं है। बेशक, आपको यह सुनिश्चित करने की आवश्यकता होगी कि php इस सुरक्षित फ़ोल्डर में भी चल सकता है।

चूंकि WP को sibling फ़ोल्डर में wp_config.php देखने के लिए कॉन्फ़िगर नहीं किया जा सकता है, जैसे / रूट / सुरक्षित, आपको एक अतिरिक्त कदम उठाना होगा। मैंने wp_config.php को / root / html में छोड़ दिया, और संवेदनशील भागों (डेटाबेस लॉगिन, नमक, टेबल उपसर्ग) को काट दिया और उन्हें config.php नामक एक अलग फ़ाइल में स्थानांतरित कर दिया। फिर आप includeअपने wp_config.php में PHP कमांड को इस तरह जोड़ें :include('/home/content/path/to/root/secure/config.php');

यह अनिवार्य रूप से मैंने अपने सेटअप में किया है। अब, उपरोक्त चर्चा के आधार पर, मैं अभी भी मूल्यांकन कर रहा हूं कि क्या यह आवश्यक है या एक अच्छा विचार भी है। लेकिन मैं सिर्फ यह जोड़ना चाहता था कि उपरोक्त विन्यास संभव है। यह आपके बैकअप और अन्य रूट फ़ाइलों को उजागर नहीं करता है, और जब तक कि सुरक्षित फ़ोल्डर अपने स्वयं के सार्वजनिक URL के साथ सेट नहीं किया जाता है, यह ब्राउज़ करने योग्य नहीं है।

इसके अलावा, आप एक .htaccess फ़ाइल बनाकर सुरक्षित फ़ोल्डर तक पहुँच को सीमित कर सकते हैं:

order deny,allow
deny from all
allow from 127.0.0.1

— माइकल
स्रोत

हे माइकल, यह साझा करने के लिए धन्यवाद। क्या आपने इसे सत्यापित करने के लिए वास्तविक वातावरण में इसे आज़माया है, हालाँकि? मुझे लगता है कि open_basedirयह निर्देश एक पूरी लेता पेड़ , इसलिए एक्सेस करने के लिए /root/secureसे /root/html, आप सेट करना होगा open_basedirकरने के लिए /root।

— इयान डन

अपने विचार को काम करने के लिए, मुझे लगता है कि आपको निर्देशिका संरचना को सेट करने की आवश्यकता होगी /root/httpdocs/config/accessible, जैसे httpdocsलॉग, बैकअप, आदि; वर्डप्रेस और सभी सामग्री को configरखता है wp-config.php, और accessibleरखता है। आपको दस्तावेज़ रूट को हटाने के लिए vhost config आदि को संशोधित करना होगा accessible। हालाँकि डिफ़ॉल्ट सेटअप में wp-config के HTTP अनुरोधों को अस्वीकार करने का मुझे कोई लाभ नहीं दिखता है।

— इयान डन

1

Php.net/manual/en/ini.core.php#ini.open-basedir के अनुसार : "विंडोज के तहत, निर्देशिकाओं को एक अर्धविराम से अलग करें। अन्य सभी प्रणालियों पर, निर्देशिकाओं को एक बृहदान्त्र के साथ अलग करें। एक अपोलो मॉड्यूल के रूप में। मूल निर्देशिका से खुले_बेडिर पथ अब स्वचालित रूप से विरासत में मिले हैं। " तो आप कई निर्देशिकाएं सेट कर सकते हैं, उनके लिए एक ही पेड़ में रहने की कोई आवश्यकता नहीं है।

— माइकल

मैंने अभी-अभी परीक्षण किया है और ऐसा लगता है कि आप सही हैं। मुझे अभी भी यकीन नहीं है कि अपाचे के माध्यम से फ़ाइल तक पहुंच से इनकार करने पर इसका क्या सुरक्षा लाभ है, हालांकि।

— इयान डन

@IanDunn ने हारून एडम्स के जवाब में अच्छी तरह से संबोधित किया

— एंड्रयूज

4

वहाँ बहुत सारे खराब लिखित विषय और प्लगइन्स हैं जो एटिकेटर्स को कोड इंजेक्ट करने की अनुमति देते हैं (टिम्थ के साथ सुरक्षा समस्या को याद रखें)। अगर मैं हमलावर होता, तो मुझे wp-config.php की खोज क्यों करनी चाहिए? बस इस कोड को इंजेक्ट करें:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

आप अपने wp-config.php को छिपाने की कोशिश कर सकते हैं। जब तक वर्डप्रेस सभी संवेदनशील जानकारी को वैश्विक सुलभ बनाता है, तब तक wp-config.php को छिपाने का कोई लाभ नहीं होता है।

Wp-config.php में बुरा हिस्सा यह नहीं है कि यह संवेदनशील डेटा रखता है। खराब हिस्सा संवेदनशील डेटा को वैश्विक सुलभ स्थिरांक के रूप में परिभाषित करना है।

अपडेट करें

मैं समस्याओं को define()स्पष्ट करना चाहता हूं और संवेदनशील डेटा को वैश्विक स्थिरांक के रूप में परिभाषित करना एक बुरा विचार क्यों है।

वेबसाइट पर हमला करने के कई तरीके हैं। स्क्रिप्ट इंजेक्शन एक वेबसाइट को नष्ट करने का केवल एक तरीका है।

सर्वर की मानें तो एक भेद्यता है जो एक हमलावर को मेमोरी डंप तक पहुंचने देती है। हमलावर मेमोरी में मिल जाएगा सभी चर के सभी मूल्यों को डंप। यदि आप एक वैश्विक सुलभ स्थिरांक को परिभाषित करते हैं, तो इसे स्क्रिप्ट समाप्त होने तक स्मृति में रहना होगा। एक निरंतर के बजाय एक वैरिएबल बनाना, एक अच्छा मौका है कि कचरा संग्रहकर्ता चर (या मुक्त) को अधिलेखित कर देगा जिसके बाद चर की आवश्यकता नहीं है।

संवेदनशील डेटा को सुरक्षित रखने का एक बेहतर तरीका यह है कि इसका उपयोग करने के तुरंत बाद उन्हें हटा दिया जाए:

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

संवेदनशील डेटा का उपयोग करने के बाद, असाइन करने nullकी मेमोरी में डेटा को अधिलेखित कर देगा। एक हमलावर को उस क्षण में मेमोरी डंप प्राप्त करना $db_conहोता है जब संवेदनशील डेटा होता है। और वह ऊपर के उदाहरण में बहुत कम समय है (यदि वर्ग डेटाबेस_हैंडलर इसकी एक प्रति नहीं बचाता है)।

— Ralf912
स्रोत

यह प्रतिक्रिया सीधे सवाल का जवाब नहीं देती है। किसी भी प्लगइन लेखक के पास वर्डप्रेस के साथ क्षेत्र का दिन हो सकता है यदि वे आपको अपना कोड स्थापित करने के लिए मनाते हैं और दुर्भावनापूर्ण इरादा रखते हैं। यह स्वेच्छा से आपके सिस्टम पर वायरस स्थापित करने से अलग नहीं है। यह तर्क wp-config.php को स्थानांतरित नहीं करने के लिए व्यर्थ है। यह कहने जैसा है कि आपकी कार में कार बम स्थापित करने से कार का अलार्म बेकार हो जाता है। तकनीकी रूप से सच है, लेकिन डब्ल्यूटीएफ?

— लांस क्लीवलैंड

2

नहीं, यह व्यर्थ नहीं है। सवाल यह है कि क्या मैं wp-config.php छिपाकर डेटाबेस अकाउंट की सुरक्षा कर सकता हूं। और जवाब स्पष्ट रूप से है: नहीं। यह उसी तरह है जैसे कि आप पूछते हैं 'क्या मैं कार अलार्म के साथ कार बम के खिलाफ अपनी कार की रक्षा कर सकता हूं?' डेटाबेस एक्सेस या एफ़टीपी एक्सेस की सुरक्षा के रूप में आपके wp-config को छिपाने से कोई अन्य लाभ नहीं है। दोनों वैश्विक दायरे में हैं। मुझे यकीन है कि हमलावरों के लिए कोड को इंजेक्ट किए बिना वैश्विक संस्करण तक पहुंच प्राप्त करने के लिए और अधिक तरीके हैं।

— राल्फ 912

मुझे नहीं लगता "मैं मूल प्रश्न में wp-config.php छिपाकर डेटाबेस खाते की रक्षा कर सकता हूं"। मूल प्रश्न था "क्या यह wp-config.php को स्थानांतरित करने के लिए समझ में आता है"। इसका जवाब बिल्कुल हाँ, IMO है। यह पूछने जैसा है कि जब आप बाहर जाते हैं तो आपको अपने सामने के दरवाजे को बंद करना चाहिए। यह कहना कि "कोई व्यक्ति आसानी से खिड़की तोड़ सकता है और वैसे भी अंदर आ सकता है, इसलिए परेशान क्यों होता है" सवाल के मूल बिंदु का जवाब नहीं देता है। IMO ने पूछा गया प्रश्न यह था, "क्या यह wp-config.php को स्थानांतरित करने के अतिरिक्त प्रयास के लायक है? ऐसा करने से कोई लाभ?" हाँ। बहुत कम से कम यह आलसी हैकर्स को बाहर रखता है।

— लांस क्लीवलैंड

2

सबसे आम सुरक्षा सर्वोत्तम प्रथाओं में से एक ... आप एक बहुत (बहुत, बहुत) महत्वपूर्ण बिंदु से चूक गए: एक हमलावर को क्या दिलचस्पी है? और यह नहीं है कि आप अपने wp-config.php स्टाइल कैसे करते हैं। एक हमलावर आपके wp-config में परिभाषित मूल्यों में इंटरसेस्ट है। अपने उदाहरण को सामने वाले दरवाजे से पकड़ना: अपने wp-config को छिपाना वैसा ही है जैसे कि आप अपने सामने वाले दरवाजे को बंद कर देंगे, लेकिन बगीचे में अपने सारे सोने को असुरक्षित रूप से स्टोर कर लें। Wp-config में परिभाषित सभी मान विश्व स्तर पर परिभाषित हैं। तो वे सभी wp-config के बाहर सुलभ हैं । यदि आप अपना wp-config छिपाते हैं, तब भी मान मौजूद हैं।

— राल्फ

1

मुझे लगता है कि जो इसे स्थानांतरित करने के पक्ष में तर्क देते हैं, वे उन परिदृश्यों से रक्षा करने की कोशिश कर रहे हैं जहां wp-config.php को HTTP अनुरोध के माध्यम से सादे पाठ में प्रदर्शित किया जा सकता है, न कि उन परिदृश्यों की तुलना में जहां यह मेजबान पर चल रहे अन्य PHP कोड के संपर्क में हो सकता है।

— इयान दून

-1

सुरक्षा लाभों के अलावा, यह आपको कोर वर्डप्रेस फ़ाइलों को सबमॉड्यूल / बाहरी के रूप में रखते हुए अपने वर्डप्रेस उदाहरण को संस्करण नियंत्रण में रखने की अनुमति भी देता है। इस तरह से मार्क जैक्विथ ने अपने वर्डप्रेस-स्केलेटन प्रोजेक्ट की स्थापना की है। देखें https://github.com/markjaquith/WordPress-Skeleton#assumptions जानकारी के लिए।

— Emzo
स्रोत

8

उसने इसे दस्तावेज़ रूट में सेटअप किया है, इसके बाहर नहीं, इसलिए यह इस प्रश्न के लिए प्रासंगिक नहीं है। जिस तकनीक के बारे में सवाल पूछा गया है वह निर्दिष्ट करती है कि आप wp-config.phpएक निर्देशिका को vhost के दस्तावेज़ रूट से ऊपर ले जाते हैं , न कि केवल वर्डप्रेस इंस्टॉलेशन फ़ोल्डर के ऊपर एक निर्देशिका। संपूर्ण बिंदु उस फ़ोल्डर के बाहर प्राप्त करना है जिसे HTTP अनुरोधों द्वारा पढ़ा जा सकता है।

— इयान डन

वेब रूट के बाहर चलती wp-config वास्तव में फायदेमंद है?

संक्षिप्त उत्तर: हाँ

दीर्घ उत्तर: एक वास्तविक दुनिया का उदाहरण

बग:

परिणाम:

wp-config.phpअपने सर्वर पर किसी भी स्थान पर कैसे जाएं

इसके विपरीत तर्क देना

तर्क 1: यदि PHP अक्षम है, तो वे पहले से ही अंदर हैं

तर्क 2: गलती से PHP को अक्षम करना दुर्लभ है, और इसलिए महत्वहीन है

तर्क 3: पहुंच से इनकार करना wp-config.phpकाफी अच्छा है

तर्क 4: अनधिकृत पहुंच wp-config.phpकोई बड़ी बात नहीं है

तर्क 5: wp-config.phpवेब रूट के बाहर जाने से वास्तव में सर्वर कम सुरक्षित हो जाता है

निष्कर्ष: विन्यास फाइल हमेशा हमेशा चाहिए हमेशा वेब जड़ के बाहर स्थित हो

`wp-config.php`अपने सर्वर पर किसी भी स्थान पर कैसे जाएं

तर्क 3: पहुंच से इनकार करना `wp-config.php`काफी अच्छा है

तर्क 4: अनधिकृत पहुंच `wp-config.php`कोई बड़ी बात नहीं है

तर्क 5: `wp-config.php`वेब रूट के बाहर जाने से वास्तव में सर्वर कम सुरक्षित हो जाता है