विश्वसनीय और सुरक्षित लिनक्स (चेम्बरलेन के लिए हमारा जवाब)

हेबेरी पर लिनक्स सिस्टम सुरक्षा के विषय पर हाल के लेखों को पढ़ने के बाद, मुझे इस मुद्दे पर अपनी बात साझा करने की इच्छा हुई।
पूरे लेख को नौसिखिए प्रशासकों के लिए डिज़ाइन किया गया है, इसलिए, यह एक अच्छे विशेषज्ञ के लिए स्पष्ट चीजों की रूपरेखा देता है। मूल्यवान जोड़ और टिप्पणियां स्वागत योग्य हैं।
मैं शायद ही तीन कारणों से कॉन्फिग फाइलों से कॉपी-पेस्ट अंश दे पाऊंगा:

1. इससे लेख की अत्यधिक वृद्धि होगी।
2. किसी ने भी मान और गूगल को रद्द नहीं किया है
3. बिंदु 2 किसी विशेषज्ञ के विकास के लिए बहुत उपयोगी है।

तो, लिनक्स पर आधारित सर्वर (और वर्कस्टेशन) की सुरक्षा और विश्वसनीयता कैसे बढ़ाएं?



मैं इस कार्य को 3 भागों में विभाजित करूंगा:

1. (प्रो) सक्रिय सुरक्षा - सिस्टम सेटिंग्स और डेमोंस को कसने। इसमें फ़ायरवॉल सेट करना भी शामिल है।
2. निष्क्रिय सुरक्षा और विश्वसनीयता - प्रणाली की निगरानी।
3. बैकअप

तंग प्रणाली सेटिंग्स

1. अप्रयुक्त सेवाओं / डेमों को अक्षम करें । प्रक्रियाओं की सूची की सावधानीपूर्वक समीक्षा करें (उदाहरण के लिए, ps -ef का उपयोग। कम कमांड) और उन लोगों की पहचान करें जिनकी आपको आवश्यकता नहीं है। सुनिश्चित करें कि उन्हें सिस्टम द्वारा ही आवश्यकता नहीं है। अक्षम करें।
2. यदि संभव हो, तो मानक पोर्ट और इंटरफेस को बदल दें, जिस पर शेष सेवाओं को सुना जाता है और स्वयं सेवाओं का उपयोग करके अतिरिक्त सुरक्षा प्रतिबंधों को कॉन्फ़िगर करता है (जो कि, उनकी कॉन्फ़िगरेशन फ़ाइलों को संपादित करके (स्टार्टअप मापदंडों में कुंजी जोड़कर) है।
   मैं sshd के उदाहरण के साथ वर्णन करूँगा। यहां निम्न करना आवश्यक है - मानक बंदरगाह को 22 वें से किसी भी मुफ्त में बदल दें, उदाहरण के लिए 6622। रूट लॉगिन के साथ पहुंच से इनकार करें। उपयोग के लिए अनुमत उपयोगकर्ता नामों की सूची को हार्ड-सेट करें। Sshd को केवल एक विशिष्ट पते पर सुनने की अनुमति दें। एक विकल्प के रूप में, केवल कुंजी द्वारा पहुंच की अनुमति दें, लेकिन मुझे वास्तव में पसंद नहीं है
   UPD कुंजियों को सर्वसम्मति से सर्वर तक पहुंचने का एक शानदार तरीका माना जाता है, इसलिए उनका उपयोग करें (लेकिन स्थायी रूप से पासवर्ड प्रविष्टि को अक्षम न करें)।
   
3. सभी सेवाएँ जो केवल सिस्टम एडमिनिस्ट्रेटर या व्यक्तियों के एक सीमित दायरे द्वारा उपयोग की जाती हैं, केवल vpn या ssh कनेक्शन के माध्यम से सुलभ होनी चाहिए।
4. जहां भी संभव हो एन्क्रिप्टेड कनेक्शन (pop3-> pops3, http-> https, आदि) का उपयोग कर स्विच करना संभव है
5. iptables
   फ़ायरवॉल को कॉन्फ़िगर करना एक बहुत ही दिलचस्प विषय है, जिसे आपको एक अलग लेख समर्पित करना होगा।
   मूल सिद्धांत इस प्रकार हैं:
   फ़ायरवॉल को एक सफेद सूची के सिद्धांत पर काम करना चाहिए, अर्थात, वह सब कुछ जो स्पष्ट रूप से अनुमति नहीं है निषिद्ध है।
   इसे प्राप्त करने के दो तरीके हैं:
   विधि संख्या 1
   डिफ़ॉल्ट फ़ायरवॉल नीति को iptables -P INPUT DROP, iptables -P OUTPUT DROP और iptables -P FORWARD DROP कमांड के साथ सेट करना। इन आदेशों के क्रियान्वयन के बाद, आने वाले, बाहर जाने वाले और पारगमन यातायात, जिसके लिए कोई अनुमति नियम नहीं बनाए गए हैं, को अवरुद्ध कर दिया जाएगा, इसलिए, उन्हें सावधानी के साथ पालन किया जाना चाहिए।
   कम से कम iptables के साथ कुछ करने से पहले, मैं दृढ़ता से सलाह देता हूं कि आप Oskar Andreasson के उत्कृष्ट मार्गदर्शक का अध्ययन करें
   इसे पढ़ते समय, लॉग के उद्देश्य (कार्रवाई) पर ध्यान दें, जो आपको सिस्टम में प्रवेश करने वाले पैकेट पर लॉग विभिन्न डेटा को लिखने की अनुमति देता है। यह फ़ायरवॉल के प्रारंभिक लेखन में बहुत मदद करता है। मैं फ़ायरवॉल स्थापित करने के लिए निम्नलिखित प्रक्रिया के बारे में सलाह दे सकता हूं:
   a) सभी आवश्यक नियम लिखिए
   ख) प्रत्येक श्रृंखला के अंत में एक लॉगिंग नियम जोड़ें (यह उन सभी पैकेटों को पकड़ेगा, जिन्हें आपने पिछले नियमों में नहीं लिया था और शब्दांश में उनके बारे में जानकारी लिखें)
   ग) फ़ायरवॉल सक्षम करें
   डी) सिसोगल में बेहिसाब यौगिकों को ढूंढें और फ़ायरवॉल में उनके लिए नियम जोड़ें।
   पैराग्राफ (डी) को तब तक दोहराया जाता है जब तक कि शब्दांश गायब नहीं हो जाते।
   यह स्पष्ट है कि आपको बिना सोचे-समझे उन सभी चीज़ों को नहीं जोड़ना चाहिए जो कि syslog में दिखाई देती हैं क्योंकि अनधिकृत पहुँच के प्रयासों के परिणाम वहाँ दिखाई देंगे।
   मैं ध्यान देता हूं कि आइटम (डी) के सफल समापन के बाद ही डिफ़ॉल्ट डीआरओपी नीति को सक्षम किया जाना चाहिए - यह सुनिश्चित करता है कि फ़ायरवॉल को डीबग करते समय मौजूदा सेवाएं काम करना जारी रखेंगी।
   मैं भी शुरुआती लोगों के लिए एक स्पष्ट क्षण नहीं नोट करता हूं:
   यहाँ एक मानक फ़ायरवॉल टेम्पलेट में से एक अंश होना चाहिए।
   iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

   ये नियम इनबाउंड और आउटबाउंड पैकेट की अनुमति देते हैं जो पहले से ही स्थापित सत्रों से संबंधित हैं।
   यह केवल स्टेटफुल प्रोटोकॉल के लिए काम करता है, विशेष रूप से tcp प्रोटोकॉल के लिए।
   यदि आप इन नियमों का उपयोग नहीं करते हैं, तो प्रत्येक आवेदन के लिए आपको 2 नियम लिखने होंगे - एक INPUT श्रृंखला के लिए, और दूसरा OUTPUT के लिए।
   यदि आप उनका उपयोग करते हैं, तो आप अपने आप को केवल एक तक सीमित कर सकते हैं, जो आपको मूल कनेक्शन स्थापित करने की अनुमति देगा।
   
   विधि संख्या 2
   प्रत्येक श्रृंखला के अंत में, एक नियम लिखें जो सभी पैकेटों को REJECT में भेजता है।
   यही है, मानक मामले में, आपको तीन नियम जोड़ने की आवश्यकता है - iptables-IN INUTUT -j REJECT, iptables-OUTPUT -j REJECT और iptables-FOR FORARD -j REJECT।
   इन नियमों को जोड़ने के परिणामस्वरूप, सभी पैकेट जिन्हें पिछले नियमों द्वारा स्पष्ट रूप से अनुमति नहीं है, उन्हें संदेश पोर्ट-अगम्य के साथ अस्वीकार कर दिया जाएगा।
   बाकी सब कुछ ठीक उसी तरह से किया जाना चाहिए जैसा कि विधि क्रमांक 1 में किया गया है, जिसमें - संबंधित संबंधित, स्थापित नियम शामिल हैं।
   
   विधि संख्या 2 वैचारिक रूप से सबसे सही है और मैं आपको इसका उपयोग करने की सलाह देता हूं, लेकिन चुनाव आपका है।
   
6. SELinux
   एक बहुत ही रोचक और आशाजनक बात। अन्यत्र प्रक्रियाओं के अधिकारों को प्रतिबंधित करता है। प्रत्येक क्रिया जो किसी प्रक्रिया को करने की अनुमति देती है, उसे एक पॉलिसी मैप में बदल दिया जाना चाहिए।
   इसी तरह की एक और प्रणाली है - अप्पर्मर (जहां तक ​​मुझे पता है, इसका उपयोग उबंटू लिनक्स में किया जाता है)।
   ईमानदारी से, मैंने अभी तक दोनों प्रणालियों के साथ मिलकर काम नहीं किया है (इसलिए, मैं कोई विशेष सिफारिशें नहीं दे सकता हूं), आंशिक रूप से एक परियोजना में SELinux का उपयोग किया है, लेकिन समय के दबाव के कारण मैं जिस समय में था, मुझे इस कार्य को अस्थायी रूप से स्थगित करना पड़ा। जल्द ही मैं निश्चित रूप से SELinux की स्थापना के लिए लौटूंगा क्योंकि मुझे यह वास्तव में पसंद आया है।
   

निगरानी

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

1. Nagios
   कई बड़े मॉनिटरिंग सिस्टम (nagios, zabbix, cacti, munin) हैं।
   मैंने उन सभी को आजमाया और अंततः नागियो पर बस गया। कॉन्फ़िगर करने के लिए बहुत सुविधाजनक और लचीला प्रणाली।
   निगरानी के लिए बड़ी संख्या में प्लग-इन, और यदि कोई उपयुक्त प्लग-इन नहीं है, तो आप अपने लिए किसी भी भाषा में सुविधाजनक तरीके से लिख सकते हैं (उदाहरण के लिए, मैं इसके लिए बैश और अजगर का उपयोग करता हूं)।
   कम से कम, आपको प्रोसेसर लोड, मेमोरी, स्वैप, फ्री डिस्क स्थान, लोड औसत की निगरानी को कॉन्फ़िगर करने की आवश्यकता है। महत्वपूर्ण सेवाओं (जैसे अपाचे, mysql, nginx, tomcat, आदि) की उपलब्धता की निगरानी करना अत्यधिक उचित है।
2. MRTG / RRD
   विभिन्न संकेतकों की गतिशीलता को एमआरटीजी का उपयोग करके उत्पन्न चार्ट पर आसानी से देखा जा सकता है।
   एमआरटीजी आपको एक सुविधाजनक रूप में विभिन्न सिस्टम मापदंडों की निर्भरता को समय पर देखने की अनुमति देता है।
   उदाहरण के लिए, आप देख सकते हैं कि दिन के समय के आधार पर प्रोसेसर और मेमोरी लोड कैसे बदलता है। आप लगभग किसी भी संकेतक के लिए ग्राफ खींच सकते हैं - प्रोसेसर के तापमान से लेकर डेटाबेस तक प्रश्नों की संख्या तक। MRTG एक प्रणाली की स्थिति का विश्लेषण करने के लिए एक अत्यंत उपयोगी उपकरण है।
   MRTG की कई सीमाएं और नुकसान हैं जिन्हें एक ही लेखक से RRD उपयोगिता का उपयोग करके दरकिनार किया जा सकता है।
3. स्मार्टड + स्मार्टमोनटूल
   आपको हार्ड ड्राइव की स्थिति की निगरानी करने और एक प्रारंभिक चरण में संदिग्ध रीडिंग की पहचान करने की अनुमति देता है। नागियोस में एकीकृत किया जा सकता है।
   उदाहरण के लिए, वैरिएबल Reallocated_Sector_Ct चर का एक गैर-शून्य मान इंगित करता है कि खराब क्षेत्र डिस्क पर दिखाई दिए, और लंबे समय तक दिखाई दिए क्योंकि स्मार्ट केवल कारखाने के रीमैप टेबल के भरे जाने के बाद बैड की उपस्थिति के बारे में पता लगाता है (यहां मैं थोड़ा गलत हो सकता है, इस बारे में सिद्धांत लंबे समय से है। मैंने इसे अपडेट नहीं किया, हो सकता है कि आधुनिक हार्ड ड्राइव के साथ बैड तुरंत स्मार्ट के माध्यम से दिखाई दे)।
   आप स्मार्टड को कॉन्फ़िगर और कॉन्फ़िगर कर सकते हैं ताकि सभी संदिग्ध रीडिंग को तुरंत प्रशासक को ईमेल किया जाए।
4. एनालाइजर लॉग करें
   यह स्पष्ट है कि त्रुटियों के लिए सिस्टम लॉग को मैन्युअल रूप से मॉनिटर करना एक धन्यवाद कार्य है।
   इस उद्देश्य के लिए, कई लॉग एनालाइजर लंबे समय से मौजूद हैं।
   मैं आपको सलाह देता हूं कि आप एक साथ कई सिस्टम लगाएं और जो आपको ज्यादा पसंद हो उसे चुनें।
   आप लॉगवॉच से शुरू कर सकते हैं।
5. रिमोट syslog
   आपको क्या लगता है कि किसी भी सिस्टम में घुस चुके हमलावर का पहला निशाना क्या है?
   लक्ष्य अपनी उपस्थिति को छिपाना है ।
   ऐसा करने के लिए, वह सिस्टम लॉग्स से अपने कार्यों के सभी संदर्भों को निश्चित रूप से हटा देगा (और कुछ सिस्टम उपयोगिताओं को बदलने की कोशिश भी करेगा, लेकिन उस पर और अधिक)।
   लॉग को हटाने के नकारात्मक परिणामों से खुद को बचाने के लिए, आपको दूरस्थ सर्वर पर उनकी रिकॉर्डिंग को व्यवस्थित करने की आवश्यकता है। यह सलाह दी जाती है कि इस सर्वर तक पहुंच असंभव है (आप इसे आईपी केवीएम के माध्यम से स्वयं एक्सेस कर सकते हैं) या बहुत मुश्किल हो, अन्यथा कुछ भी पटाखा को वहां संग्रहीत लॉग की अनमॉडिफाइड कॉपी को हटाने से रोक नहीं पाएगा। लॉग सर्वर पर ही, किसी भी डीबीएमएस में लॉग को स्टोर करना सबसे सुविधाजनक है।
   
6. एड्स और एड्स
   HIDS सिस्टम की स्थिति पर नज़र रखता है (लॉग, सिस्टम उपयोगिताओं की अखंडता, आदि) और, अगर सुरक्षा उल्लंघन का संदेह है, तो इसके बारे में व्यवस्थापक को सूचित करें। यह मदद करेगा कि पिछले पैराग्राफ से हमलावर अपनी उपस्थिति को छिपाने या सिस्टम में एक लॉगिन को सुरक्षित करने के लिए किसी भी सिस्टम उपयोगिता की जगह लेता है। उदाहरण के लिए, आप उपयोगिताओं को प्रतिस्थापित कर सकते हैं ps, जो, w, अंतिम है ताकि व्यवस्थापक यह न देख सके कि वर्तमान में सिस्टम में कौन लॉग इन है। Iptables और sshd उपयोगिताओं को बदलें ताकि वे हमलावर को सिस्टम में स्वतंत्र रूप से लॉग इन करने की अनुमति दें।
   HIDS, निश्चित रूप से इस तरह के कार्यों को रोकने में सक्षम नहीं होगा, लेकिन यह व्यवस्थापक को उनके बारे में सूचित करने में सक्षम होगा।
   HIDS का एक उदाहरण OSSEC है।
   
   NIDS यदि HIDS सिस्टम की आंतरिक स्थिति की निगरानी करता है, तो NIDS संदिग्ध नेटवर्क गतिविधि (पोर्ट स्कैन, पासवर्ड प्रयास, सिस्टम सेवाओं के खिलाफ विभिन्न हमले आदि) का विश्लेषण करता है। सबसे अच्छा ज्ञात NIDS Snort है।

बैकअप

1. जैसा कि आप जानते हैं, सिस्टम प्रशासक उन लोगों में विभाजित हैं जो बैकअप नहीं लेते हैं, जो पहले से ही उन्हें करते हैं और जो सोचते हैं कि वे उन्हें करते हैं।
   यह कहावत गहरे अर्थ से भरी हुई है।
   कई मामलों में बैकअप की आवश्यकता हो सकती है, उदाहरण के लिए, सिस्टम के साथ हार्डवेयर समस्याओं के बाद, इसे हैक करने के बाद, व्यवस्थापक या डेवलपर द्वारा गलत कार्यों के बाद।
   आप बैकअप को फाइल सिस्टम बैकअप और डेटाबेस बैकअप में सशर्त रूप से विभाजित कर सकते हैं।
   बैकअप को संग्रहीत करने के लिए एक अलग सर्वर होना बहुत ही वांछनीय है, आदर्श रूप से अन्य सभी उपकरणों से भी अलग से स्थित है। अलग-अलग, इसका मतलब है 5 किलोमीटर की दूरी पर, कोई कम नहीं।
   
   बैकअप के लिए बहुत से विभिन्न सॉफ्टवेयर लिखे गए हैं, लेकिन मैं व्यक्तिगत रूप से मेरे द्वारा लिखी गई स्क्रिप्ट का उपयोग करना पसंद करता हूं। इसलिए मुझे इस प्रक्रिया पर पूरा नियंत्रण मिलता है।
   फ़ाइल सिस्टम बैकअप के लिए, उपयुक्त कुंजियों के साथ rsync का उपयोग करना आसान है। ज्यादातर मामलों में, वृद्धिशील बैकअप करना अधिक सुविधाजनक होता है।
   डेटाबेस बैकअप के लिए, DBMS निर्माताओं द्वारा प्रदान की गई उपयोगिताओं का उपयोग करना सबसे अच्छा है, लेकिन mysql के मामले में मैं इस नियम से थोड़ा दूर चला गया।
   मानक बैकअप उपयोगिता - बैकअप को हटाते समय mysqldump बहुत अच्छा व्यवहार नहीं करता है, अर्थात्, यह लिखने के लिए तालिकाओं को "लॉक" करता है, बैकअप के समय उन पर लिखना प्रतिबंधित करता है (हालांकि निर्दोष के मामले में यह पूरी तरह से बचा जा सकता था, लेकिन mysqldump सक्षम नहीं है यह करने के लिए)। बड़े डेटाबेस का उपयोग करते समय यह बहुत सही है, कम से कम 10-20 जीबी आकार में, जहां टेबल लॉक 10-20 मिनट तक रह सकता है। इसके अलावा, इस तरह के बैकअप से बड़े डेटाबेस की बहाली में कई घंटे लगते हैं।
   ऐसी स्थिति में, मास्टर-> दास प्रणाली का उपयोग करना अधिक उचित है।
   बैकअप सर्वर पर, mysql दास डेटाबेस के लिए कॉन्फ़िगर किया गया है जिसे बैकअप करने की आवश्यकता है। भविष्य में, बैकअप अब मुख्य आधार से नहीं, बल्कि उसके दास से निकाले जाएंगे। दुर्घटना की स्थिति में, आप डेटाबेस को तुरंत बहाल भी नहीं कर सकते हैं, लेकिन बस दास सर्वर के सभी अनुरोधों को पुनर्निर्देशित करेंगे, जो कि बहुत समय लगेगा। दास सर्वर से बैकअप को हटाने और इसकी प्रारंभिक तैयारी के लिए पेरकोना से इनोबैकअपएक्स उपयोगिता का उपयोग करना सुविधाजनक है। उदाहरण के लिए, यह आपको मुख्य डेटाबेस को रोके बिना (लेखन के लिए लॉक किए बिना) गुलाम सर्वर के बाद के बैकअप के लिए उपयुक्त बनाने की अनुमति देता है।
   एक और बहुत महत्वपूर्ण बिंदु है - यह समय-समय पर उनकी शुद्धता के लिए बैकअप की जांच करने के लिए आवश्यक है, अन्यथा आप सबसे अपर्याप्त समय पर खाली या टूटे हुए अभिलेखागार को खोजने का जोखिम चलाते हैं।
   

सभी सर्वरों के लिए प्रलेखन (विकी में उदाहरण के लिए) रखना बहुत महत्वपूर्ण है और सर्वर सेटिंग्स में किसी भी बदलाव के साथ इसे अपडेट करना न भूलें। बहुत बार ऐसे मामले होते हैं जब सिस्टम प्रशासक उस सिस्टम को स्थापित करने के विवरण को याद नहीं कर सकता है जिसके साथ उसने लंबे समय तक काम नहीं किया है।

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

PS लेख ने टिप्पणियों में चर्चा के परिणामों के आधार पर कुछ सुधार किए। जो भी बोले सबका धन्यवाद।