सर्वर पर सॉफ़्टवेयर चलाने के लिए मुझे नया उपयोगकर्ता खाता कब बनाना चाहिए?

Question

सामान्य तौर पर, किसी को सर्वर पर इंटरनेट-फेसिंग सॉफ़्टवेयर के टुकड़े को चलाने के लिए नया उपयोगकर्ता खाता कब बनाना चाहिए?

उदाहरण के लिए, मान लें कि मैं एक साझा डेबियन सर्वर (उदाहरण के लिए ड्रीमहोस्ट के माध्यम से) का उपयोग कर रहा हूं और मैं वर्डप्रेस का उपयोग करके कुछ वेबसाइटें चलाना चाहता हूं, कुछ रेडमाइन का उपयोग कर रहा हूं, कुछ रेल्स पर रूबी का उपयोग कर रहे हैं, शायद कुछ Django का उपयोग कर रहे हैं, और मैं मर्क्यूरियल की सेवा करना चाहता हूं रिपोजिटरी भी।

ड्रीमहॉस्ट सर्वर और इसी तरह के अन्य सेट-अप सर्वरों पर, यह सब एक ही उपयोगकर्ता खाते के तहत किया जा सकता है , लेकिन मैं उस दृष्टिकोण में कुछ कमियां देख सकता हूं:

• एक लंबा .bashrc
• यदि वह एक खाता समझौता हो जाता है, तो उसके तहत चलने वाली सभी साइटें करें।

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

सबसे अच्छा अभ्यास क्या है? क्या यह केवल प्रतिमानों के स्तर के अनुपात में प्रति उपयोगकर्ता खाते में होस्ट की गई साइटों (या होस्ट किए गए रिपॉजिटरी, आदि) की संख्या को कम करने का सवाल है?

कृपया इस पर अपनी राय दें, उनके कारण बताएं।

इसके अलावा, यदि आपके पास यह सोचने का कोई कारण है कि एक निजी सर्वर या वीपीएस पर लिया गया दृष्टिकोण एक साझा सर्वर पर लिए गए दृष्टिकोण से अलग होना चाहिए, तो कृपया बताएं कि वे क्या हैं और फिर से, उनके लिए आपके कारण।

Answer 1

मैं आम तौर पर "एक उपयोगकर्ता के लिए एक प्रशंसक हूं जो नेटवर्क पर सुनने वाले सॉकेट को खोलता है" - एक अपाचे के लिए, एक मेल के लिए, एक DNS के लिए, आदि।

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

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

प्रत्येक अपाचे को चुरोट (या जेल में यदि आप बीएसडी सिस्टम पर) डालने के तर्क को और अधिक सुरक्षा के लिए बनाया जा सकता है, लेकिन अब आप अतिरिक्त डिस्क स्थान के बारे में बात कर रहे हैं क्योंकि प्रत्येक चेरोट / जेल को आवश्यक सभी सॉफ़्टवेयर की आवश्यकता होगी उस साइट को चलाएं जिसमें (और पैच के बाहर आने पर सर्वर पर केवल एक मास्टर कॉपी के बजाय हर साइट के लिए इस सॉफ़्टवेयर को अपडेट करने की आवश्यकता है), साथ ही रैम की आवश्यकता तब ही होती है जब आपके पास अलग-अलग उपयोगकर्ता / अपाचे इंस्टेंसेस थे।
यह ओएस / कर्नेल बग को छोड़कर सब कुछ कम कर देता है जो उपयोगकर्ताओं को चेरोट से बाहर निकलने देता है (जो एक अलग भौतिक सर्वर पर हर साइट को चलाने के लिए तर्क बन जाता है - जो फिर अलग-अलग vlans / सबनेट, आदि में साइटों को अलग करने के लिए तर्क बन जाता है)

---

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

Comments

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

— क्रॉमी

@Kromey, मुझे mod_su के बारे में अधिक जानकारी नहीं मिल सकी। क्या आपका मतलब mod_suexec है ?

— सम्पाब्लोकपर

@sampablokuper यप, वह एक होगा, गलत सूचना के लिए खेद है।

— क्रॉमी

@Kromey के साथ बड़ी समस्या mod_suexecयह है कि "गैर-सीजीआई अनुरोध अभी भी उपयोगकर्ता के निर्देश में निर्दिष्ट उपयोगकर्ता के साथ प्रक्रियाएं हैं" - इसलिए यदि PHP एक मॉड्यूल है तो यह अभी भी "मुख्य" अपाचे उपयोगकर्ता के रूप में चल रहा है। यह एक बढ़िया समाधान है अगर आप जो कुछ भी निष्पादित कर रहे हैं वह CGI है।

— voretaq7

@voretaq आह, मैं उस सीमा के बारे में पता नहीं था। फिर भी, कुछ वातावरणों में उपयोगी हो सकता है, लेकिन यह वास्तव में इसे कम लागू करता है जितना मैंने सोचा था कि यह था।

— क्रॉमी

Answer 2

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

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

Comments

+1 पृथक्करण का स्तर हाथ में स्थिति के लिए उपयुक्त होना चाहिए - और आम तौर पर एक बार जब आप "बहुत विवादास्पद" या "वित्तीय डेटा" प्राप्त करते हैं, तो आप मेरे स्वयं के अलग होने के मशीन स्तर चाहते हैं: :-)

— voretaq7