सवाल क्या उत्पादन सर्वर को स्थापित करना सुरक्षित है?


मेरे वर्चुअल सर्वर उदाहरणों के सेटअप के दौरान मुझे कुछ अनुप्रयोगों का उपयोग करने के लिए उपयोग करने की आवश्यकता है make। क्या कोई सुरक्षा जोखिम जुड़े हुए हैं make स्थापित? या उदाहरण को तैनात करने से पहले इसे साफ़ करना चाहिए?

मेरे पास भी है gcc सर्वर पर संकलक जो मैं तैनाती से पहले अनुप्रयोग बनाने के लिए उपयोग करता हूं।


39
2018-05-15 17:46


मूल


अगर यह आपको बेहतर महसूस करता है, कोई भी सॉफ्टवेयर का टुकड़ा स्थापित कहीं भी एक भेद्यता बनाता है। - MDMoore313
और एक सर्वर के लिए गैर रूट रूट एक्सेस के साथ एक "distro स्वतंत्र" कंपाइलर पैकेज (.tar.gz) डाउनलोड कर सकता है जिसे इंस्टॉल करने की आवश्यकता नहीं है ... - nwildner
क्या यह मैं हूं, या "क्या यह सुरक्षित है" का संयोजन है? और "रूट पहुंच" बल्कि असुविधाजनक? - DNA
यदि आपके पास पहले से ही जीसीसी स्थापित है, तो व्यावहारिक रूप से ऐसा कोई तरीका नहीं है जिससे कोई संभावित सुरक्षा समस्या खराब हो सके। - Shadur
@ शडुर जीसीसी बनाने में क्या अंतर है? यदि उपयोगकर्ता के पास पहले से ही मशीन तक पहुंच है तो वे जीसीसी की किसी भी प्रति को तीन बार अपलोड कर सकते हैं। वैसे भी, जीसीसी अप्रतिबंधित उपयोगकर्ताओं के लिए उपयोगी हो सकता है, न कि जब तक कोई विशेषाधिकार प्राप्त उपयोगकर्ता इसे चलाता है तब तक सुरक्षा जोखिम नहीं। - Vality


जवाब:


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

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

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

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

मैं उपरोक्त में से किसी एक से मिलान करने के लिए विकास उपकरण की अपेक्षा नहीं करता, और क्योंकि यह एक उच्च जोखिम पैकेज नहीं है।

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

यदि आपको लगता है कि आपको सर्वर पर उन उपकरणों की वास्तव में आवश्यकता नहीं है, तो आपको उन्हें कई कारणों से इंस्टॉल करने से बचना चाहिए:

  • सर्वर और बैकअप पर डिस्क स्थान बचाता है।
  • कम स्थापित सॉफ़्टवेयर ट्रैक करना आसान बनाता है कि आपकी निर्भरता क्या है।
  • यदि आपको पैकेज की आवश्यकता नहीं है, तो अतिरिक्त सुरक्षा जोखिम को स्थापित करने में कोई बात नहीं है, भले ही वह सुरक्षा जोखिम छोटा हो।

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


48
2018-05-15 18:27



मैं इसमें जोड़ूंगा कि कई उत्पादन प्रणाली व्याख्या किए गए कोड (जैसे PHP, पर्ल, पायथन, ...) पर भरोसा करते हैं। इस संदर्भ में विकास उपकरण को प्रतिबंधित करना समझ में नहीं आता है। मैं कंपाइलर्स की तरह विचार करता हूं gcc इन से अधिक जोखिम पेश नहीं करना है। जैसा कि आप कहते हैं, एक सिस्टम पर स्थापित कंपाइलर्स का उपयोग करने की स्थिति में एक हमलावर आम तौर पर वैसे भी बदतर चीजों को करने की स्थिति में होता है, जैसे कि अपने स्वयं के (संभावित रूप से स्थाई रूप से जुड़े) निष्पादन योग्य अपलोड करना। - Bruno
प्रासंगिक: Wget का एक छोटा संस्करण (51 बाइट्स?)। एक हमलावर का वास्तविक जीवन उदाहरण बाद में उपयोग करने के लिए सर्वर पर बाइनरी ले जा रहा है echo एक फाइल में बयान। पूरी प्रक्रिया एक ही लिंक में मिली एक स्क्रिप्ट के साथ स्वचालित है। - Adi
@ अदनान, दिलचस्प। जहां तक ​​मैं कह सकता हूं, इस डीवीआर उदाहरण में मुख्य सुरक्षा दोष यह तथ्य है कि हमलावर इसे पहले स्थान पर पासवर्ड 123456 के साथ रूट के रूप में टेलनेट कर सकता है। Wget या अन्य उपकरण (हमले से पहले) होने या नहीं होने के बाद वास्तव में मुश्किल से प्रासंगिक है। - Bruno


make एक खोल है जिसमें से एक अलग वाक्यविन्यास है bash

एक कंपाइलर की तरह gccएक शक्तिशाली है awk मानक के एक सेट के साथ कॉन्फ़िगर किया गया मानक awk समर्थन नहीं करता। यह एक गैर-पॉज़िक्स-अनुरूप है sort या cat जो आउटपुट में बकवास इंजेक्ट करता है। यह एक इंटरेक्टिव टेक्स्ट एडिटर है (सोचो vi) जो स्टार्टअप पर कुछ संपादन करने के लिए कॉन्फ़िगर किया गया है, फिर उपयोगकर्ता इंटरफ़ेस प्रदर्शित करने से पहले बाहर निकलें।

उनमें स्वाभाविक रूप से असुरक्षित कुछ भी नहीं है, वे आपकी मशीन को एक से अधिक असुरक्षित नहीं बनाते हैं जहां आपके पास बैश है + cat + खोल पुनर्निर्देशन।


15
2018-05-16 16:54



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


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

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

नोट: मूल पैकेजिंग उपकरण चूसना। उन्हें ग्रोक करने की कोशिश भी परेशान मत करो। इसके बजाय, जॉर्डन सिसिल की जांच करें fpm। यह पैकेजिंग को एक पूर्ण खुशी बनाता है।


15
2018-05-15 17:49



मैं यहां जिज्ञासा और अज्ञानता से पूछ रहा हूं: आप क्यों कहते हैं कि कंपाइलर्स की उपस्थिति एक "महत्वपूर्ण सुरक्षा समस्या" है? एक कंपाइलर स्थापित करने के साथ सुरक्षा समस्या क्या है? क्या यह सिर्फ एक मामला है कि आप पहले कोड में उत्पादन कोड पर अपना कोड नहीं बना रहे हैं और इस प्रकार संकलक अनिवार्य है, या वास्तव में संकलक की उपस्थिति के साथ वास्तव में एक महत्वपूर्ण सुरक्षा समस्या है? - reirab
हालांकि, एक अलग सर्वर पर अपने अनुप्रयोगों का निर्माण करना एक अच्छा विचार है, कह रहा है कि उत्पादन प्रणाली पर कंपाइलर्स की मौजूदगी एक महत्वपूर्ण सुरक्षा समस्या है, यह समझ में नहीं आता है। स्क्रिप्टिंग भाषाओं और जेआईटी-संकलित सिस्टम (पर्ल, पायथन, जावा, ...) के बारे में क्या? - Bruno
उत्पादन वातावरण पर कंपाइलरों की उपस्थिति है नहीं एक "महत्वपूर्ण सुरक्षा जोखिम"। मैं, मैंने, समझौता किए गए बक्से का उपयोग करके द्विआधारी स्थानांतरित कर दिए हैं echo तथा base64। वास्तव में, आप भी कर सकते हैं इसे एक श्रृंखला के साथ करो echo बयान और कोई अन्य उपकरण नहीं। - Adi
अच्छा अंक, सब। मैंने स्पष्टीकरण के लिए अपना जवाब संपादित कर लिया है। - EEAA


इसके विपरीत, संभावित मुद्दा होने के साथ नहीं है make उत्पादन सर्वर पर, संभावित समस्या परीक्षण पूर्व-निर्मित छवियों को तैनात करने के बजाय उत्पादन सर्वर पर अनुप्रयोगों के निर्माण के साथ है। इस पद्धति के लिए वैध कारण हो सकते हैं, लेकिन यह एक है जिसे मैं दृढ़ता से तर्क दूंगा कि मैंने इसे अपनाने के लिए कहा था।


9
2018-05-15 17:49





आप पूछ रहे हैं कि क्या make एक उत्पादन सर्वर पर स्थापित किया जाना चाहिए, लेकिन मेरा असली सवाल यह होगा: उस उत्पादन सर्वर तक किसके पास पहुंच है और घुसपैठ से निपटने के लिए आपके पास कौन से सुरक्षा उपाय हैं? अगर make स्थापित नहीं किया गया था लेकिन कोई लाभ root पहुंच, अनुमान लगाओ क्या? वे मैन्युअल रूप से स्थापित कर सकते हैं make और वे चाहते हैं कि कुछ भी।

कंप्यूटर सुरक्षा के बारे में कठोर वास्तविकता उतना ही है जितना आप अवांछित पहुंच को रोकना चाहते हैं, अवरुद्ध पहुंच के साथ भ्रमित होने के नाते उतना महत्वपूर्ण नहीं है जितना:

  1. सर्वर तक किसके पास पहुंच है?
  2. ब्रेक के बाद से रोलबैक के लिए आप क्या कर सकते हैं?

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


4
2018-05-16 21:50





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

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


1
2018-05-17 14:56