लिनक्स वेबसर्वर पर मेरी वेबसाइट फ़ाइलों / फ़ोल्डरों की क्या अनुमति होनी चाहिए?

Question

यह लिनक्स वेब सर्वर पर फ़ाइल अनुमतियों के बारे में एक कैननिकल प्रश्न है।

मेरे पास एक लिनक्स वेब सर्वर है जो अपाचे 2 को चलाता है जो कई वेबसाइटों को होस्ट करता है। प्रत्येक वेबसाइट का अपना फ़ोल्डर / var / www / में होता है।

/var/www/contoso.com/
/var/www/contoso.net/
/var/www/fabrikam.com/

आधार निर्देशिका / var / www / रूट द्वारा स्वामित्व में है: रूट। Apache www-data: www-data के रूप में चल रही है। फैब्रिकम वेबसाइट को दो डेवलपर्स, एलिस और बॉब द्वारा बनाए रखा गया है। दोनों Contoso वेबसाइटों को एक डेवलपर ईव द्वारा बनाए रखा जाता है। सभी वेबसाइट उपयोगकर्ताओं को चित्र अपलोड करने की अनुमति देती हैं। यदि किसी वेबसाइट से समझौता किया जाता है, तो प्रभाव यथासंभव सीमित होना चाहिए।

मैं अनुमतियाँ सेट करने का सबसे अच्छा तरीका जानना चाहता हूं ताकि Apache सामग्री की सेवा कर सके, वेबसाइट हमलों से सुरक्षित रहे, और डेवलपर्स अभी भी बदलाव कर सकें। वेबसाइटों में से एक इस तरह संरचित है:

/var/www/fabrikam.com
    /cache
    /modules
    /styles
    /uploads
    /index.php

इन निर्देशिकाओं और फ़ाइलों पर अनुमतियाँ कैसे सेट की जानी चाहिए? मैंने कहीं पढ़ा है कि आपको किसी वेबसाइट पर 777 अनुमतियों का उपयोग नहीं करना चाहिए, लेकिन मुझे समझ में नहीं आता है कि क्या समस्याएं हो सकती हैं। व्यस्त अवधि के दौरान, वेबसाइट स्वचालित रूप से कुछ पृष्ठों को कैश करती है और परिणामों को कैश फ़ोल्डर में संग्रहीत करती है। वेबसाइट विज़िटर द्वारा सबमिट की गई सभी सामग्री अपलोड फ़ोल्डर में सहेजी जाती है।

Comments

यह उन सभी सवालों के लिए एक विहित उत्तर देने का इरादा है जो हमें वेबसाइट की अनुमति के बारे में मिलते हैं।

— निक

"मैंने कहीं पढ़ा है कि आपको कभी भी 777 अनुमतियों का उपयोग किसी वेबसाइट पर नहीं करना चाहिए, लेकिन मुझे समझ नहीं आया ..." - तो क्या पाठक समझ पाएंगे या कम से कम यहां उत्तरों की खूबियों की तुलना करने में सक्षम होंगे? कोई भी समाधान विशिष्ट आवश्यकताओं के आधार पर होना चाहिए - यहां की आवश्यकताएं पर्याप्त विशिष्ट नहीं हैं (खतरे का मॉडल क्या है)

— सिम्बियन

मुझे पसंद है कि आप अपाचे के बारे में पूछ रहे हैं, लेकिन उन डोमेन का उपयोग कर रहे हैं जो Microsoft आमतौर पर उदाहरण के रूप में उपयोग करता है।

— 21 अक्टूबर को gWaldo

यह भी देखें कि apache2 के उपयोगकर्ता www-data / in / var / www के लिए अनुमतियों को संभालने का सबसे अच्छा तरीका क्या है?

— गैरेथ

आप यहाँ उन अनुमतियों के बारे में पूरी जानकारी के लिए उल्लेख कर सकते हैं जिन्हें वेबसाइट के फाइलों और फ़ोल्डरों को linux serverfault.com/questions/124800/…

Answer 1

यह तय करते समय कि आपको किन अनुमतियों का उपयोग करना है, आपको यह जानना होगा कि आपके उपयोगकर्ता कौन हैं और उनकी क्या आवश्यकता है। एक वेबसर्वर दो प्रकार के उपयोगकर्ता के साथ सहभागिता करता है।

प्रमाणीकृत उपयोगकर्ताओं का सर्वर पर एक उपयोगकर्ता खाता होता है और उन्हें विशिष्ट विशेषाधिकार प्रदान किए जा सकते हैं। इसमें आमतौर पर सिस्टम प्रशासक, डेवलपर्स और सेवा खाते शामिल होते हैं। वे आमतौर पर एसएसएच या एसएफटीपी का उपयोग करके सिस्टम में बदलाव करते हैं।

अनाम उपयोगकर्ता आपकी वेबसाइट के विज़िटर हैं। हालाँकि, उनके पास फ़ाइलों को सीधे एक्सेस करने की अनुमति नहीं है, वे एक वेब पेज और अपनी ओर से वेब सर्वर कार्य करने का अनुरोध कर सकते हैं। वेब सर्वर प्रक्रिया की क्या अनुमति है, इस बारे में सावधान रहकर आप अनाम उपयोगकर्ताओं की पहुंच को सीमित कर सकते हैं। कई लिनक्स वितरण पर, अपाचे www-dataउपयोगकर्ता के रूप में चलता है लेकिन यह अलग हो सकता है। उपयोग करें ps aux | grep httpdया ps aux | grep apacheदेखें कि आपके सिस्टम पर उपयोगकर्ता Apache क्या उपयोग कर रहा है।

---

लिनक्स अनुमतियों पर नोट्स

लिनक्स और अन्य POSIX- अनुरूप सिस्टम पारंपरिक यूनिक्स अनुमतियों का उपयोग करते हैं। फाइलसिस्टम अनुमतियों के बारे में विकिपीडिया पर एक उत्कृष्ट लेख है इसलिए मैं यहाँ सब कुछ नहीं दोहराऊँगा। लेकिन कुछ चीजें हैं जिनसे आपको अवगत होना चाहिए।

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

डिफ़ॉल्ट नई फ़ाइल अनुमतियाँ
जब एक फ़ाइल बनाई जाती है, तो यह सामान्य रूप से जिसने भी इसे बनाया है, उसके समूह आईडी को विरासत में मिला है। लेकिन कभी-कभी आप नई फ़ाइलों को फ़ोल्डर के समूह आईडी को प्राप्त करना चाहते हैं जहां वे बनाई जाती हैं, इसलिए आप मूल फ़ोल्डर में SGID बिट को सक्षम कर सकते हैं।

डिफ़ॉल्ट अनुमति मान आपके umask पर निर्भर करते हैं। Umask नई बनाई गई फ़ाइलों से अनुमतियों को घटाता है, इसलिए 755 के साथ बनाई जा रही फ़ाइलों में 022 परिणामों का सामान्य मूल्य है। एक समूह के साथ सहयोग करते समय, यह आपके umask को 002 में बदलने के लिए उपयोगी है ताकि आपके द्वारा बनाई गई फ़ाइलों को समूह के सदस्यों द्वारा संशोधित किया जा सके। और यदि आप अपलोड की गई फ़ाइलों की अनुमतियों को अनुकूलित करना चाहते हैं, तो आपको फ़ाइल अपलोड होने के बाद एपाचे के लिए umask को बदलना होगा या chmod को चलाना होगा।

---

777 के साथ समस्या

जब आप chmod 777अपनी वेबसाइट बनाते हैं, तो आपके पास कोई सुरक्षा नहीं होती है। सिस्टम का कोई भी उपयोगकर्ता आपकी वेबसाइट की किसी भी फ़ाइल को बदल या हटा सकता है। लेकिन अधिक गंभीरता से, याद रखें कि वेब सर्वर आपकी वेबसाइट पर आगंतुकों की ओर से कार्य करता है, और अब वेब सर्वर उन्हीं फाइलों को बदलने में सक्षम है जिन्हें यह निष्पादित कर रहा है। यदि आपकी वेबसाइट में कोई प्रोग्रामिंग भेद्यताएं हैं, तो उनका उपयोग आपकी वेबसाइट को खराब करने, फ़िशिंग हमलों को सम्मिलित करने, या आपके सर्वर से जानकारी चोरी करने के लिए किया जा सकता है।

इसके अतिरिक्त, यदि आपका सर्वर एक जाने-माने पोर्ट पर चलता है (जो कि गैर-रूट उपयोगकर्ताओं को स्पॉनिंग सुनने की सेवाओं को रोकने के लिए है जो विश्व-सुलभ हैं), तो इसका मतलब है कि आपका सर्वर रूट द्वारा शुरू किया जाना चाहिए (हालांकि कोई भी सेंस सर्वर तुरंत बंद हो जाएगा एक कम-विशेषाधिकार प्राप्त खाते में एक बार बंदरगाह बंधे होने के बाद)। दूसरे शब्दों में, यदि आप एक वेबसर्वर चला रहे हैं, जहां मुख्य निष्पादन योग्य संस्करण नियंत्रण (उदाहरण के लिए एक CGI ऐप) का हिस्सा है, तो इसकी अनुमति (या, उस मामले के लिए, युक्त निर्देशिका की अनुमति, जिससे उपयोगकर्ता नाम बदल सकता है। 777 पर निष्पादन योग्य) किसी भी उपयोगकर्ता को किसी भी निष्पादन योग्य को रूट के रूप में चलाने की अनुमति देता है ।

---

आवश्यकताओं को परिभाषित करें

• डेवलपर्स को फ़ाइलों को पढ़ने / लिखने की आवश्यकता होती है ताकि वे वेबसाइट को अपडेट कर सकें
• डेवलपर्स को निर्देशिकाओं को पढ़ने / लिखने / निष्पादित करने की आवश्यकता होती है ताकि वे चारों ओर ब्राउज़ कर सकें
• अपाचे को फ़ाइलों और व्याख्या की गई स्क्रिप्ट तक पहुंच की आवश्यकता है
• अपाचे को सेवा योग्य निर्देशिकाओं तक पहुंच को पढ़ने / निष्पादित करने की आवश्यकता होती है
• अपाचे को अपलोड की गई सामग्री के लिए निर्देशिकाओं को पढ़ने / लिखने / निष्पादित करने की आवश्यकता है

---

एक एकल उपयोगकर्ता द्वारा बनाए रखा

यदि साइट को बनाए रखने के लिए केवल एक उपयोगकर्ता जिम्मेदार है, तो उन्हें वेबसाइट निर्देशिका पर उपयोगकर्ता के मालिक के रूप में सेट करें और उपयोगकर्ता को पूर्ण rwx अनुमतियां दें। अपाचे को अभी भी एक्सेस की आवश्यकता है ताकि यह फ़ाइलों की सेवा कर सके, इसलिए समूह स्वामी के रूप में www-data सेट करें और समूह rx अनुमतियाँ दें।

आपके मामले में, ईव, जिसका उपयोगकर्ता नाम हो सकता eveहै, एकमात्र उपयोगकर्ता है जो बनाए रखता है contoso.com:

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

यदि आपके पास फ़ोल्डर हैं जिन्हें अपाचे द्वारा लिखने योग्य होने की आवश्यकता है, तो आप बस समूह स्वामी के लिए अनुमति मान को संशोधित कर सकते हैं ताकि www-data लेखन तक पहुंच हो।

chmod g+w uploads
ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

इस कॉन्फ़िगरेशन का लाभ यह है कि सिस्टम पर अन्य उपयोगकर्ताओं के लिए यह मुश्किल हो जाता है (लेकिन असंभव नहीं है) चारों ओर सूँघने के लिए, क्योंकि केवल उपयोगकर्ता और समूह के मालिक ही आपकी वेबसाइट निर्देशिका को ब्राउज़ कर सकते हैं। यह उपयोगी है यदि आपके पास अपनी कॉन्फ़िगरेशन फ़ाइलों में गुप्त डेटा है। अपने umask के बारे में सावधान रहें! यदि आप यहां एक नई फ़ाइल बनाते हैं, तो अनुमति मान शायद 755 तक डिफ़ॉल्ट होंगे। आप इसे चला सकते हैं umask 027ताकि नई फाइलें 640 ( rw- r-- ---) तक डिफ़ॉल्ट हो जाएं ।

---

उपयोगकर्ताओं के एक समूह द्वारा बनाए रखा

यदि साइट को बनाए रखने के लिए एक से अधिक उपयोगकर्ता जिम्मेदार हैं, तो आपको अनुमतियाँ असाइन करने के लिए उपयोग करने के लिए एक समूह बनाना होगा। प्रत्येक वेबसाइट के लिए एक अलग समूह बनाना और उस वेबसाइट के बाद समूह का नाम देना अच्छा है।

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

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

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

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

chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

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

आप अपना केक ले सकते हैं और इसे भी खा सकते हैं

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

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

यदि आपके पास फ़ोल्डर हैं जिन्हें अपाचे द्वारा लिखने योग्य होने की आवश्यकता है, तो आप उपयोगकर्ता स्वामी के लिए अनुमति मूल्यों को केवल संशोधित कर सकते हैं ताकि www-data लेखन तक पहुंच हो।

chmod u+w uploads
ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

इस समाधान से सावधान रहने वाली एक बात यह है कि नई फ़ाइलों का उपयोगकर्ता स्वामी www-डेटा पर सेट होने के बजाय निर्माता से मेल खाएगा। इसलिए आपके द्वारा बनाई गई कोई भी नई फ़ाइल अपाचे द्वारा पठनीय नहीं होगी जब तक आप उन्हें चाउ नहीं करते।

---

* अपाचे विशेषाधिकार जुदाई

मैंने पहले उल्लेख किया है कि यह वास्तव में आपकी वेबसाइट के आसपास अन्य उपयोगकर्ताओं के लिए संभव है कि आप किस तरह के विशेषाधिकारों का उपयोग कर रहे हैं। डिफ़ॉल्ट रूप से, सभी Apache प्रक्रियाएं एक ही www-data उपयोगकर्ता के रूप में चलती हैं, इसलिए कोई भी Apache प्रक्रिया उसी सर्वर पर कॉन्फ़िगर की गई अन्य सभी वेबसाइटों की फ़ाइलों को पढ़ सकती है, और कभी-कभी परिवर्तन भी कर सकती है। कोई भी उपयोगकर्ता जो अपाचे को स्क्रिप्ट चलाने के लिए प्राप्त कर सकता है, वही एक्सेस प्राप्त कर सकता है जो अपाचे के पास है।

इस समस्या से निपटने के लिए, अपाचे में विशेषाधिकार पृथक्करण के विभिन्न दृष्टिकोण हैं । हालांकि, प्रत्येक दृष्टिकोण विभिन्न प्रदर्शन और सुरक्षा कमियों के साथ आता है। मेरी राय में, उच्च सुरक्षा आवश्यकताओं वाली किसी भी साइट को एक साझा सर्वर पर VirtualHosts का उपयोग करने के बजाय एक समर्पित सर्वर पर चलाया जाना चाहिए।

---

अतिरिक्त मुद्दो पर विचार करना

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

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

अधिक जटिल आवश्यकताओं वाली वेबसाइट के लिए, आप एक्सेस कंट्रोल लिस्ट के उपयोग पर गौर कर सकते हैं । ये विशेषाधिकारों के अधिक परिष्कृत नियंत्रण को सक्षम करते हैं।

यदि आपकी वेबसाइट की जटिल आवश्यकताएं हैं, तो आप एक स्क्रिप्ट लिखना चाहते हैं जो सभी अनुमतियों को सेट करती है। इसे अच्छी तरह से परखें, फिर सुरक्षित रखें। यह सोने में इसके वजन के लायक हो सकता है यदि आप कभी भी किसी कारण से अपनी वेबसाइट को फिर से बनाने की आवश्यकता महसूस करते हैं।

Comments

"chmod -R 775 fabrikam.com"। अधिकांश वेबसाइटों के अंदर बहुत कम फ़ाइलों को निष्पादन योग्य होना चाहिए; जैसे php स्क्रिप्ट 0640 हो सकती है जब तक वेब सर्वर उन्हें पढ़ सकता है। chmod -R a + X fabrikam.com सभी को केवल निर्देशिका पर निष्पादन योग्य अधिकार देगा।

ध्यान दें कि अपाचे apacheRed Hat व्युत्पन्न सिस्टम पर उपयोगकर्ता के रूप में चलता है।

— माइकल हैम्पटन

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

— idiotprogrammer

यह उत्तर, व्यापक है, केवल DAC अनुमतियों से संबंधित है। मुझे लगता है कि MAC अनुमतियों को भी माना जाना चाहिए।

— '23:

यह एक उत्कृष्ट पोस्ट है। यहाँ मेरा योगदान है: समूह के रूप में स्वामी और देव-फ़ेब्रिकम के रूप में www-डेटा का उपयोग करने का नकारात्मक पक्ष ( आप में उल्लेख किया गया है कि आपका केक हो सकता है और खा सकते हैं यह भी एक उपयोगकर्ता द्वारा बनाए गए परिदृश्य में प्रस्तुत किए गए रिवर्स में) लागू होता है । परिदृश्य, जब भी अपाचे एक फ़ोल्डर या फ़ाइल बनाता है, तो उपयोगकर्ता के पास इसका उपयोग नहीं होगा इसलिए फ़ाइलों को मूल उपयोगकर्ता को वापस भेजने की आवश्यकता है। मैंने उत्तर को अपडेट नहीं किया है क्योंकि मैं अपने कथन के बारे में 100% सुनिश्चित नहीं हूं मैं जवाब देने से पहले दूसरों से इसकी पुष्टि करना चाहता हूं।

Answer 2

मैं सोच रहा हूं कि इतने सारे लोग लिनक्स अधिकारों के "अन्य" (ओ) हिस्से का उपयोग (या सिफारिश) करते हैं कि वे अपाचे (और / या PHP) क्या कर सकते हैं। इस सही हिस्से को "0" के अलावा किसी और चीज़ में सेट करके, आप पूरी दुनिया को फ़ाइल / निर्देशिका पर कुछ करने की अनुमति देते हैं।

मेरा दृष्टिकोण निम्नलिखित है:

• मैं दो अलग उपयोगकर्ता बनाते हैं। SSH / SFTP एक्सेस (यदि आवश्यक हो) के लिए एक, जो सभी फाइलों का मालिक होगा, और PHP FastCGI उपयोगकर्ता (वेबसाइट के रूप में चलेगा उपयोगकर्ता) के लिए एक। चलो इन उपयोगकर्ताओं को क्रमशः बॉब और बॉब-www कहते हैं ।
• बॉब पूर्ण अधिकार (होगा rwx फ़ोल्डरों पर, rw- ताकि वह / वह पढ़ सकते हैं और पूरी वेबसाइट संपादित कर सकते हैं, फाइलों पर)।
• पीएचपी FastCGI प्रक्रिया की जरूरत है rx फोल्डर और पर अधिकार r-- की तरह बहुत विशिष्ट फ़ोल्डरों के लिए छोड़कर, फाइलों पर अधिकार cache/या uploads/, जहां "लिखने" अनुमति भी जरूरी है। PHP FastCGI को यह क्षमता देने के लिए, यह bob-www के रूप में चलेगा , और bob-www स्वचालित रूप से बनाए गए बॉब समूह में जुड़ जाएगा ।
• अब हम यह सुनिश्चित करते हैं कि सभी निर्देशिकाओं और फ़ाइलों के स्वामी और समूह बॉब बॉब हैं ।
• कुछ याद आ रही है: यहां तक ​​कि हम FastCGI का उपयोग करते हैं, लेकिन अपाचे को अभी भी स्थिर सामग्री, या .htaccess फ़ाइलों के लिए पढ़ने की पहुंच की आवश्यकता है, अगर AllowOverrideयह पढ़ने की कोशिश करेगा कि क्या कुछ और से सेट किया गया है None। अधिकारों के o भाग का उपयोग करने से बचने के लिए, मैं bob समूह में www-data उपयोगकर्ता को जोड़ता हूं ।

अभी:

• यह नियंत्रित करने के लिए कि डेवलपर क्या कर सकता है, हम अधिकारों के यू भाग के साथ खेल सकते हैं (लेकिन यह नीचे नोट है)।
• अपाचे और PHP क्या कर सकते हैं इसे नियंत्रित करने के लिए, हम अधिकारों के जी भाग के साथ खेल सकते हैं ।
• ओ हिस्सा हमेशा 0 पर सेट है, तो सर्वर पर और कोई नहीं पढ़ सकते हैं या वेबसाइट संपादित कर सकते हैं।
• जब बॉब उपयोगकर्ता नई फाइल बनाता है तो कोई समस्या नहीं है , क्योंकि यह स्वचालित रूप से अपने मुख्य समूह ( बॉब ) से संबंधित होगा ।

यह एक पुनरावृत्ति है, लेकिन इस स्थिति में, एसएसएच को बॉब की अनुमति है। यदि वेबसाइट को संशोधित करने के लिए किसी भी उपयोगकर्ता की अनुमति नहीं होनी चाहिए (उदाहरण के लिए ग्राहक केवल एक सीएमएस व्यवस्थापक पैनल के माध्यम से वेबसाइट को संशोधित करता है और लिनक्स ज्ञान नहीं है), वैसे भी दो उपयोगकर्ता बनाएं, लेकिन बॉब के/bin/false लिए शेल भी दें, और इसके लॉगिन को निष्क्रिय करें।

    adduser --home /var/www/bobwebsite --shell /bin/bash bob
    adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

नोट: लोग यह भूल जाते हैं कि यू (मालिक) अधिकारों को सीमित करना सबसे अधिक समय बेकार और असुरक्षित है, क्योंकि किसी फ़ाइल का मालिक chmodकमांड चला सकता है , यहां तक ​​कि अधिकार 000 भी हैं।

मुझे बताएं कि क्या मेरे दृष्टिकोण में कुछ सुरक्षा मुद्दे हैं, क्योंकि मैं 100% निश्चित नहीं हूं, लेकिन यह वही है जो मैं उपयोग कर रहा हूं।

मुझे लगता है कि इस विन्यास में एक समस्या है: जब PHP / Apache एक नई फ़ाइल (जैसे अपलोड) बनाता है, तो यह bob-www: bob से संबंधित होगी , और bob केवल इसे पढ़ सकेगा। हो सकता है कि निर्देशिका पर सेतु समस्या का समाधान कर सके।

Comments

लिनक्स अनदेखा करता है setuid। नई फाइलें हमेशा निर्माता के स्वामित्व में होती हैं।

— पॉल

मुझे कुछ समझ नहीं आ रहा है। यह उस स्थिति को सम्‍मिलित नहीं करता है जब वेबसाइट पर अधिक डेवलपर एक साथ काम करते हैं, चूंकि एकमात्र उपयोगकर्ता है bob। आप इससे कैसे निपटते हैं? उदाहरण के लिए। ssh के माध्यम से, दोनों उपयोगकर्ता बॉब के रूप में लॉग इन करते हैं। बॉब (1) को लगता है कि वह पासवर्ड याद नहीं रख सकता है और इसे दूसरे में बदल सकता है लेकिन फिर भी सुरक्षित है। बॉब (2) अगली बार में प्रवेश करने की कोशिश करता है, और वह नहीं कर सकता।

— n611x007

@naxa किसी भी मामूली अच्छी प्रणाली को कभी भी किसी भी डेवलपर को सीधे वेबसाइट को संशोधित नहीं करना चाहिए। आदर्श रूप से, वेबसाइट संस्करण नियंत्रण के अधीन है जैसे कि उपयोगकर्ता खाता 'बॉब' स्वचालित रूप से प्रत्येक (स्थिर) रिलीज को खींचता और हटाता है। इसलिए, डेवलेपमेंट सर्वर पर धकेल दिए जाने के बाद, डेवलपर डेवलपमेंट ऑफसाइट करते हैं, और बदलाव हो जाता है। 'बॉब' एक प्रणाली उपयोगकर्ता है जिसके पास बहुत सीमित नेटवर्क अनुमतियाँ होनी चाहिए, जिसमें दूरस्थ लॉगिन शामिल नहीं है; iptables वास्तव में आपको इस तरह से सामान के लिए UID द्वारा फ़िल्टर करने की अनुमति देता है।

— पार्थियन ने

"मैं सोच रहा हूं कि इतने सारे लोग" अन्य "(ओ) भाग का उपयोग (या अनुशंसा) क्यों करते हैं - तो शायद आपको उत्तर के बजाय प्रश्न के रूप में इसे पोस्ट करना चाहिए था। यह जानबूझ कर वेबसर्वर (प्रणाली का सबसे उजागर हिस्से के रूप में) विशेषाधिकार के निम्नतम स्तर के साथ चलाने के लिए असामान्य बात नहीं है, जबकि समर्थन, विकास, व्यवस्थापक खाते भी विभिन्न पहुँच की जरूरत है

— symcbean

@ParthianShot आप उसे तीसरे पक्ष (जब साइट आपके द्वारा बनाए रखा नहीं है, लेकिन फ़ोल्डर आपके सर्वर में मौजूद है) के लिए मजबूर नहीं कर सकते। कभी-कभी केवल वे ही जानते हैं कि एफ़टीपी का उपयोग करके क्या करना है।

— पेरेरिंग-एलके

Answer 3

उपरोक्त उत्कृष्ट उत्तर पर Google रैंक को देखते हुए, मुझे लगता है कि एक बात है जिसे नोट किया जाना चाहिए, और मैं उत्तर के बाद एक नोट छोड़ने के लिए प्रतीत नहीं कर सकता।

उदाहरण के साथ आगे बढ़ते हुए, यदि आप निर्देशिका (या फ़ाइल) पर 570 अनुमतियों के साथ समूह के रूप में www-डेटा को स्वामी और देव-फ़ेब्रिकम के रूप में उपयोग करने की योजना बनाते हैं, तो यह ध्यान रखना महत्वपूर्ण है कि लिनक्स उपेक्षा करता है setuid , इसलिए सभी नई फ़ाइलों का स्वामित्व होगा उपयोगकर्ता जो उन्हें बनाया है। इसका मतलब यह है कि नई निर्देशिका और फाइलें बनाने के बाद आपको कुछ इसी तरह का उपयोग करना होगा:

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

रैकस्पेस ओपनस्टैक के लिए उबंटू 12.04 में, मेरे पास एक अजीब मुद्दा था जहां मुझे 570 को काम करने की अनुमति नहीं मिल सकती थी जब तक कि मैंने सर्वर को रिबूट नहीं किया, जिसने जादुई रूप से इस मुद्दे को तय किया। लगता है कि साधारण मुद्दे पर बढ़ती दर से बाल झड़ रहे थे ...।

Comments

कृपया इसे गुगली होने दें: रास्पबियन में (रास्पबेरी पाई पर उर्फ, यदि आप lighttpd (या किसी अन्य वेब ब्राउज़र) के तहत / var / www के स्वामित्व को बदलना चाहते हैं, तो आपको जरूरी रीबूट करना होगा।

— gbbner

@ जीबीरनर यदि उस समस्या को हल करने के लिए एक मुश्किल मुद्दा है, तो आप इसे एक प्रश्न के रूप में पोस्ट करने और प्रश्न का उत्तर प्रदान करने पर विचार कर सकते हैं। हालाँकि, यह शायद अलग एसई क्यू एंड ए साइट में अधिक उपयुक्त है। मेरा अनुमान है कि यूनिक्स और लिनक्स ऐसा करने के लिए एक अच्छी जगह हो सकती है।

— पॉल

वहाँ भी है raspberrypi.stackexchange.com; ऐसा लगता है कि SE साइटें ज्ञान को थोड़ा बढ़ा रही हैं।

— ग्रोनर

@ ग्रोनर लोल। मैं उस एक के बारे में नहीं जानता था! U & L पर रास्पबियन टैग में 120 प्रश्न कुछ हैं।

— पॉल

Answer 4

मैं इस विन्यास के साथ जा रहा हूँ:

1. मालिक rootऔर समूह के लिए एक सेट अपलोड करने के अलावा सभी निर्देशिकाएं root, अनुमतियाँ 0755।
2. सभी फ़ाइलें स्वामी rootऔर समूह के लिए सेट की गईं root, अनुमतियाँ 0644।
3. स्वामी root, समूह www-data, अनुमतियों को निर्धारित निर्देशिका अपलोड करता है 1770। चिपचिपा सा समूह स्वामी को निर्देशिका और फ़ाइलों को हटाने या नाम बदलने की अनुमति नहीं देता है।
4. अपलोडर के अंदर www-data, स्वामी उपयोगकर्ता और समूह के साथ एक नई निर्देशिका फ़ोल्डर और फ़ाइलों को अपलोड करने वाले 0700प्रत्येक www-dataउपयोगकर्ता के लिए अनुमतियाँ ।
5. अपाचे विन्यास:

अस्वीकार करें AllowOverrideऔर Indexअपलोड निर्देशिका में, ताकि Apache .htaccessफ़ाइलें न पढ़ें , और Apache उपयोगकर्ता अपलोड फ़ोल्डर की सामग्री को अनुक्रमित नहीं कर सकता:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.iniविन्यास:

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

इस कॉन्फ़िगरेशन के साथ, www-dataउपयोगकर्ता के अलावा siteDir/ /tmpऔर के अंदर निर्देशिका प्राप्त करने में सक्षम नहीं होगा /usr/share/phpmyadmin। इसके अलावा, आप एक ही अनुरोध में अपलोड करने के लिए अधिकतम फ़ाइल आकार, अधिकतम पोस्ट आकार और अधिकतम फ़ाइलों को नियंत्रित कर सकते हैं।

Answer 5

जब आपके पास "leo" नामक एक FTP उपयोगकर्ता है, तो उसे files को example.com वेब निर्देशिका में अपलोड करने की आवश्यकता होती है और आपको अपने "apache" उपयोगकर्ता की भी आवश्यकता होती है, जो कैश निर्देशिका में uploa-files / session / cache files बनाने में सक्षम हो, तो निम्न प्रकार से करें:

यह कमांड उदाहरण के लिए Apache के रूप में स्वामी और समूह के रूप में leo को असाइन करता है। apache उपयोगकर्ता समूह अपाचे का एक हिस्सा है, इसलिए यह अपाचे समूह की अनुमतियों को इनहेरिट करेगा

chown -R leo: apache example.com

एक अन्य आदेश जो सही अनुमति देता है और साथ ही सुरक्षा चिंताओं को पूरा करता है।

chmod -R 2774 example.com

यहां पहले नंबर 2 निर्देशिका के लिए है और बनाई गई प्रत्येक नई फ़ाइल उसी समूह और स्वामी अनुमतियों में रहेगी। 77 मालिक और समूह के लिए है, जिसका मतलब है कि उनकी पूरी पहुंच है। 4 अन्य लोगों के लिए इसका मतलब है कि वे केवल गर्त पढ़ सकते हैं।

निम्नलिखित अनुमति संख्याओं को समझने में मददगार है

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7

Answer 6

IMO को ध्यान में रखना होगा:

• क्या आपको ऐसी प्रक्रिया पर भरोसा है जो आपकी फ़ाइलों को पढ़ती है? जैसे। पीएचपी?

मान लेते हैं कि आपके पास एक सर्वर है जो उपयोगकर्ता 'परीक्षण' के तहत विभिन्न डेटा है।

'परीक्षण' उपयोगकर्ता के पास है:

• में उसका डेटा $HOMEDIR
• में उसका मेल $MAIL
• में वेब के लिए उसका डेटा /var/www/test

अब आइये सोचते हैं:

• एक वेब ऐप testयूजर (PHP-FPM) के तहत चलता है - यह उसकी किसी भी फाइल को डिलीट कर सकता है!
• एक वेब ऐप testग्रुप (PHP-FPM) के तहत चलता है - यह उसकी किसी भी फाइल को डिलीट कर सकता है, जहां डायरेक्टरी में ग्रुप के लिए 'w' होता है और ग्रुप के लिए 'r' वाली किसी भी फाइल को संशोधित कर सकता है; और यह अभी भी उन्हें पढ़ सकता है - उदाहरण के लिए आपकी ssh कुंजियाँ!

मान लें कि PHP छोटी गाड़ी है, और यह है, क्या आपको इसका भरोसा है open_basedir? क्या आप chrootअपने PHP प्रक्रिया? आप क्या नहीं है, क्या आप चाहते हैं कि यह सभी फाइल सिस्टम के माध्यम से क्रॉल करता है?

आपकी वेब ऐप प्रक्रिया, उदा। PHP-FPM, तो चाहिए:

• के माध्यम से विशिष्ट पथ तक ही सीमित रहें chroot
• डेटा स्वामी के प्राथमिक उपयोगकर्ता या प्राथमिक समूह की अनुमति के तहत नहीं चलना चाहिए

इस प्रकार आप कर सकते हैं:

• परीक्षण उपयोगकर्ता है: test:test
• परीक्षण उपयोगकर्ता एक माध्यमिक समूह में होता है उदा। test-www
• एक वेब ऐप (PHP-FPM) के तहत चलता है test-www:test-www
• उपयोगकर्ता का परीक्षण करें यदि वह चाहता है कि वेब ऐप उसकी फ़ाइलों को पढ़ सकता है: chmod u=rwX,g=rX,o= /var/www/test/public
• उपयोगकर्ता का परीक्षण करें यदि वह चाहता है कि वेब ऐप उसके वेब डेटा पथ में लिख सकता है: chmod u=rwX,g=rwXs,o= /var/www/test/public/upload (इस प्रकार ऐप नई फाइलें बनाएगा: test-www:test-www- यह निर्देशिका पर सेटगाइड के कारण परीक्षण-www समूह होगा!)

इस प्रकार, यदि वेब ऐप प्रक्रिया फर्जी होगी, तो यह केवल विशिष्ट फाइलों को पढ़ेगी, जिसमें समूह रीडिंग होगी, और यह uploadकेवल डीआईआर को लिखने में सक्षम होगा । मैं दृढ़ता से अनुशंसा करता हूं कि विकल्पों के uploadसाथ फाइलसिस्टम पर dir noexec,nodev,nosuid mountकरें और उस निर्देशिका में किसी भी नई bizzare फ़ाइलों के लिए निरंतर निगरानी रखें, साथ ही test-wwwuid के तहत किसी भी नई प्रक्रियाओं की निगरानी भी करें ।

लिनक्स पर बेहतर ट्यून अनुमतियों के लिए एसीएल का उपयोग किया जा सकता है। यदि एक से अधिक मानव को वेब डेटा अपलोड करना चाहिए, तो वेब डेटा फ़ाइलों को अपलोड करने के लिए उपयोग किए जाने वाले खाते से मानव खाते को विभाजित करना बेहतर होगा। नया खाता बनाने के लिए। test-upload, और परीक्षण उपयोगकर्ता ssh कुंजियों को प्रबंधित करने के लिए प्रतिबंधित करेगा जो मानव ssh / sftp कर सकता है। विकल्पों sshd_configको जानता है कि ExposeAuthInfoयह लॉग इन करने के लिए कॉन्फ़िगर किया जा सकता है कि डेटा अपलोड करने के लिए किस ssh कुंजी का उपयोग किया गया था।

मुझे वास्तव में संदेह है कि अधिकांश वेबहोस्टिंग सेवाओं को विशेषाधिकारों के पृथक्करण की परवाह है, जब वे बिना किसी जानकारी के 'सुरक्षित' लिखते हैं, तो मैं कहूंगा कि वे झूठ बोलते हैं।

Comments

php-fpm की अनुमति है chrootऔर user, groupएक पूल के लिए सेट किया जाना है। लेकिन मुझे php_admin_value[open_basedir]विकल्प पर भरोसा नहीं होगा । मैंने यह भी पढ़ा है कि प्रति उपयोगकर्ता एक अलग PHP-FPM मास्टर होना बेहतर है, देखें ma.ttias.be/a-better-way-to-run-php-fpm सबसे लिनक्स पर एक डेमॉन को आसान बनाना आसान है और * BSF डिस्ट्रोस ।

— जिरी बी