सवाल एक लैंप सर्वर सुरक्षित करने के लिए युक्तियाँ


यह है एक कैननिकल प्रश्न एक लैंप स्टैक सुरक्षित करने के बारे में

एलएएमपी सर्वर को सुरक्षित करने के लिए पूर्ण दिशानिर्देश क्या हैं?


91
2017-12-14 01:52


मूल




जवाब:


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

सबसे पहले, यह देखने के लिए जांचें कि क्या आपके संगठन की कोई कठोर नीतियां हैं, क्योंकि ये सबसे सीधे प्रासंगिक हो सकती हैं। यदि नहीं, आपकी भूमिका के आधार पर, यह उन्हें बनाने के लिए एक अच्छा समय हो सकता है। मैं नीचे से ऊपर से प्रत्येक घटक को अलग करने की सलाह भी दूंगा।

एल
आपकी मदद करने के लिए बहुत सारे अच्छे गाइड उपलब्ध हैं। यह सूची आपके वितरण के आधार पर आपकी सहायता कर सकती है या नहीं।

द ए
अपाचे सुरक्षित करने के लिए मजेदार हो सकता है। मुझे ओएस को कड़ी मेहनत करना और अपाचे या PHP की तुलना में उपयोगिता को बनाए रखना आसान लगता है।

उन्हें

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

  • Hardening PHP - कुछ मामूली चर्चा, आईटी सुरक्षा एसई साइट पर भी।
  • कठोर PHP परियोजना - मुख्य परियोजना जो उत्पादन करती है Suhosin, कुछ प्रकार के हमलों के खिलाफ परियोजना के लिए PHP अनुप्रयोग को पैच करने का प्रयास।
  • Suhosin के साथ PHP Hardening - विशेष रूप से सुहोसिन के लिए एक संक्षिप्त हाउटो
  • Php.ini से PHP को Hardening - कुछ सुरक्षा संबंधित रनटाइम विकल्पों पर लघु, लेकिन खराब चर्चा नहीं

105
2017-12-14 14:50



मैं इस जवाब को कम से कम 10 बार वोट देना चाहता हूं। - user58859
मूक एन - या तो आईपीटीबल्स या बाहरी फ़ायरवॉल के साथ, नेटवर्क कनेक्शन को ब्लॉक करने के लिए केवल लोगों के लिए आवश्यक है। - Matt
यह एक समुदाय विकी होना चाहिए - Brian Adkins
फ़ायरवॉल को भूलना इतना आसान है। मैंने किसी ऐसे व्यक्ति के बारे में सुना जिसने वेबसाइट के लिए एक वेब सर्वर बनाया और यहां तक ​​कि जहां तक ​​पोर्ट 80 नहीं था यातायात को फेंकने के लिए टीसीपी / आईपी स्टैक हैकिंग तक चला गया। एक और चीज जो अनदेखा हो जाती है वह अनावश्यक सेवाएं है - अगर इसकी आवश्यकता नहीं है चालू होने के लिए, इसे बंद करें। - Aaron Mason
@AaronMason: बधाई हो! आपके पास एक सफल उपाख्यान है। आइए याद रखें कि आपकी विशिष्ट स्थिति अच्छी तरह से काम करती है, लेकिन उम्मीद है कि भावी पाठक आपके असामान्य वातावरण को समझेंगे। सामान्य मामले में यह सलाह बहुत खतरनाक है। - Scott Pack


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

  1. अपडेट करते रहें। इसका मतलब है कि ओएस, सभी सेवाएं, और विशेष रूप से आपके द्वारा चलाए जा रहे सभी वेबपृष्ठ।
  2. किसी भी अनियंत्रित सेवाओं को अक्षम करें, न्यूनतम एक्सपोजर के लिए आवश्यक लोगों को सीमित करें (यदि आप दूरस्थ रूप से MySQL से कनेक्ट नहीं हैं, तो यह टीसीपी पर नहीं सुन रहा है), और होस्ट-आधारित फ़ायरवॉल चलाएं। (यदि यह सख्ती से लैंप है, तो आपको 80 और 443 के साथ अच्छा होना चाहिए, लेकिन एसएसएच के साथ-साथ प्रशासन के लिए भी होना चाहिए।))
  3. मजबूत पासवर्ड का प्रयोग करें। बेहतर अभी तक, यदि आप एसएसएच का उपयोग करते हैं, तो केवल कुंजी-आधारित ऑथ का उपयोग करें।
  4. सुनिश्चित करें कि आप रूट के रूप में लॉग इन नहीं कर रहे हैं। उपयोगकर्ताओं के रूप में लॉग इन करें और su & sudo का उपयोग करें।
  5. हालांकि यह चीजों को और अधिक सुरक्षित नहीं बनाता है, आपको लॉगवॉच जैसे टूल चलाएंगे ताकि आपको पता चल सके कि आपके सर्वर पर क्या हो रहा है।

उम्मीद है कि आपको शुरू करने में मदद करता है।


13
2017-12-14 02:23



मैं एनएसए द्वारा लिखे गए "Red Hat Enterprise Linux 5 के सुरक्षित विन्यास के लिए गाइड" पढ़ने का सुझाव दूंगा - ALex_hha
पार्टी के लिए देर हो चुकी है, लेकिन मैंने हाल ही में पढ़ा है कि "रूट के रूप में लॉग इन नहीं करना" अब इतना बड़ा सौदा नहीं है, खासकर यदि आप सार्वजनिक / निजी कुंजी के आधार पर एसएसएच ऑथ का उपयोग कर रहे हैं। - the0ther


यहां एक अच्छी चेकलिस्ट है जिसे मैं शुरू करना चाहता हूं।

फ़ायरवॉल

  • एक अच्छा तरीका है कि किसी भी यातायात के साथ शुरू करने की अनुमति न दें केवल आपको जो चाहिए वह खोलें, जैसा कि आपको इसकी आवश्यकता है। इसका परिणाम खोलने में परिणाम चीजें काम करने के लिए न्यूनतम बंदरगाह / ips और यह आपके को कम करता है अनावरण।
  • एक एलएएमपी सर्वर के लिए आपको केवल बंदरगाह खोलने की आवश्यकता हो सकती है sysadmins के लिए दुनिया के लिए http / https और ssh।
  • सुनिश्चित करें कि आईपीवी 6 यातायात जैसी चीजें इसे इस्तेमाल नहीं कर रही हैं
  • एडब्ल्यूएस सुरक्षा समूहों को प्रदान करता है, लिनक्स में iptables के साथ-साथ चुनने के लिए बहुत से पैकेज हैं से।

एसएसएच और उपयोगकर्ता

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

डेटाबेस

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

सॉफ्टवेयर

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

7
2017-08-10 08:08





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

इसका क्या अर्थ है: यदि या तो अपाचे उपयोगकर्ता या MySQL उपयोगकर्ता से समझौता किया गया है, तो वे फ़ोल्डर (ओं) के दायरे के बाहर कोई नुकसान नहीं कर सकते हैं अपाचे के पास (अपाचे उपयोगकर्ता के मामले में) और तालिका के बाहर ( एस) / डेटाबेस (एस) (MySQL डेटाबेस के लिए उपयोगकर्ता के मामले में)।

यदि किसी भी तरह MySQL उपयोगकर्ता से समझौता किया जाना था, तो उदाहरण के लिए, वे डेटाबेस तक पहुंच नहीं सकते थे और सभी डेटाबेस को MySQL से छोड़ सकते थे और आपके सभी डेटा को बर्बाद कर सकते थे। वे कुछ परिस्थितियों में कुछ अलग-अलग डेटाबेस में कुछ टेबलों में तालिकाओं को छोड़ने या जानकारी डालने में सक्षम हो सकते हैं, यही कारण है कि केवल तालिका पहुंच प्रदान करना महत्वपूर्ण है जहां यह बिल्कुल जरूरी है और केवल अनुमतियों की आवश्यकता है ... यदि आप ' टी को टेबल टेबल विशेषाधिकार या विशेषाधिकार अपडेट करने की आवश्यकता नहीं है, फिर उन्हें उस उपयोगकर्ता को न दें।

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

उदाहरण का समय! मैं इस विचार को सरल बनाने के लिए एक सिस्टम उदाहरण देने जा रहा हूं।

मान लें कि आपके पास आपके सिस्टम पर उपयोगकर्ता हैं (रूट को umod -l या passwd -l, आदि जैसे कुछ के माध्यम से सुरक्षा के लिए अक्षम किया जाना चाहिए): जॉन, बर्नी, टेरेंस, और लिसा।

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

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

साथ ही, आप केवल कुछ उपयोगकर्ताओं को एसएसएच एक्सेस प्रतिबंधित कर सकते हैं (या कुछ समूह, मैं उन्हें एसएसएच समूह में रखना चाहता हूं, और एसएसएच का उपयोग करने में सक्षम एकमात्र चीज)।

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

इसलिए, प्रत्येक सेगमेंट को मॉड्यूलर करके, अगर किसी के साथ समझौता किया गया है, तो पूरे स्टैक से समझौता नहीं किया जाएगा और आप स्क्रैच से फिर से शुरू करने के बजाय 1 समस्या का समाधान कर सकते हैं।


4
2017-07-30 04:49





मुझे यह दस्तावेज़ SANS.org से वास्तव में उपयोगी पाया गया http://www.sans.org/score/checklists/linuxchecklist.pdf


2
2017-08-10 11:50



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


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

एलएएमपी के मामले में, उदाहरण के लिए, एसएसएच-सर्वर, अपाचे, माईएसक्यूएल, पीएचपी-एफपीएम / पायथन / पर्ल / आदि के साथ चार डॉकर कंटेनर का उपयोग करना संभव है।


0
2017-07-27 20:00