सत्यापित एक्सेस और रिकवरी मार्ग से शुरू करें, फिर व्यक्तिगत प्रशासन, परीक्षित SSH कुंजियाँ, प्रतिबंधात्मक फ़ायरवॉल, अनुरक्षित सॉफ़्टवेयर और स्वतंत्र बैकअप कॉन्फ़िगर करें। परिवर्तन क्रमशः लागू करें और पुराना सत्र बंद करने से पहले नया सत्र सत्यापित करें।
एक भरोसेमंद शुरुआती बिंदु स्थापित करें
मशीन बदलने से पहले अपेक्षित ऑपरेटिंग सिस्टम, एक्सेस विधि और रिकवरी मार्ग की पुष्टि करें। ऑपरेटर की स्वीकृत जानकारी के माध्यम से SSH होस्ट की पहचान सत्यापित करें, बिना जाँच के किसी अप्रत्याशित कुंजी को स्वीकार न करें। अस्थायी क्रेडेंशियल निजी रखें और उन्हें इच्छित प्रक्रिया से बदलें। रिकॉर्ड करें कि रखरखाव के लिए कौन ज़िम्मेदार है और इस सेवा के लिए वास्तव में कौन-से रिकवरी विकल्प उपलब्ध हैं।
एक्सेस परिवर्तन करते समय एक कार्यशील प्रशासन सत्र खुला रखें। कॉपी किया गया हार्डनिंग रेसिपी एकमात्र उपयोगी लॉगिन हटा सकती है जब वह किसी भिन्न डिस्ट्रीब्यूशन या खाता लेआउट को मान लेती है। एक बार में एक परिवर्तन करें, उसका प्रभावी परिणाम जाँचें और वापसी का मार्ग सुरक्षित रखें। लक्ष्य ऐसा सिस्टम है जिसे आप सुरक्षित रूप से बनाए रख सकें, न कि ऐसा कॉन्फ़िगरेशन जो सख्त दिखे पर प्रशासित न हो सके।
SSH एक्सेस को सोच-समझकर बनाएँ
एक साझा स्थायी रूट लॉगिन साझा करने के बजाय उपयुक्त विशेषाधिकार के साथ व्यक्तिगत प्रशासनिक एक्सेस बनाएँ। इच्छित सार्वजनिक कुंजी इंस्टॉल और परीक्षण करें, निजी कुंजी को अधिकृत एंडपॉइंट पर रखें। Ubuntu OpenSSH दस्तावेज़ सर्वर कॉन्फ़िगरेशन और प्रमाणीकरण विकल्प समझाता है। यह मानने से पहले कि एक सेटिंग संपादित करने से पूरी सेवा बदल गई है, अपने डिस्ट्रीब्यूशन का प्रभावी कॉन्फ़िगरेशन, शामिल फ़ाइलों सहित, पढ़ें।
पासवर्ड प्रमाणीकरण या विशेषाधिकार प्राप्त लॉगिन नियम बदलने से पहले दूसरे सत्र के माध्यम से कुंजी एक्सेस का परीक्षण करें। सुनिश्चित करें कि नया खाता आवश्यक प्रशासन कर सकता है। पिछली विधि पर निर्भर किसी भी ऑटोमेशन की समीक्षा करें और उसका एक्सेस सोच-समझकर बदलें। कुंजी एक एक्सेस क्रेडेंशियल है, इसलिए निजी भंडारण स्थान और रोटेशन प्रक्रिया का उपयोग करें, उसकी प्रतियाँ एप्लिकेशन निर्देशिकाओं में न छोड़ें।
पूरी मशीन नहीं, एप्लिकेशन को एक्सपोज़ करें
लिसनिंग सेवाओं की सूची बनाएँ और पहचानें कि कौन-सी सार्वजनिक होनी चाहिए। किसी वेब एप्लिकेशन को HTTP और HTTPS की आवश्यकता हो सकती है, जबकि उसका डेटाबेस केवल इच्छित आंतरिक मार्ग से पहुँच-योग्य रह सकता है। Ubuntu UFW को फ़ायरवॉल कॉन्फ़िगरेशन टूल के रूप में दस्तावेज़ित करता है, लेकिन उपयोगी नीति टूल से स्वतंत्र है: आवश्यक ट्रैफ़िक की अनुमति दें और जहाँ व्यावहारिक हो, प्रशासन को स्वीकृत स्रोतों तक सीमित करें।
यदि सेवा में होस्ट-स्तरीय और प्रदाता-स्तरीय नियंत्रण दोनों शामिल हैं, तो दोनों जाँचें। प्रतिबंधात्मक नियम सेट सक्षम करने से पहले परीक्षित प्रशासन मार्ग की अनुमति दें और दूसरे सत्र से एक्सेस सत्यापित करें। यह न मानें कि SSH को किसी भिन्न पोर्ट पर ले जाने से प्रमाणीकरण या पैचिंग का विकल्प मिल जाता है। फ़ायरवॉल नियम समझने योग्य रखें ताकि भविष्य में समस्या-निवारण के दौरान हर पोर्ट खोलने के वर्कअराउंड तक न पहुँचना पड़े।
| परिवर्तन | लागू करने से पहले जाँचें | बाद में जाँचें |
|---|---|---|
| नई SSH कुंजी | सही खाता और सार्वजनिक कुंजी | दूसरा कुंजी-प्रमाणित सत्र काम करता है |
| प्रतिबंधित फ़ायरवॉल | आवश्यक सेवा और रिकवरी मार्ग | सार्वजनिक ऐप काम करता है; अनपेक्षित पोर्ट बंद हैं |
| सॉफ़्टवेयर अपडेट | बैकअप और पुनःआरंभ के प्रभाव | सेवाएँ पुनःआरंभ होती हैं और एप्लिकेशन परीक्षण पास होते हैं |
| सेवा अनुमति परिवर्तन | आवश्यक पढ़ने और लिखने के मार्ग | ऐप व्यापक सिस्टम एक्सेस के बिना काम करता है |
अपडेट की योजना एक परिचालन प्रक्रिया के रूप में बनाएँ
सिस्टम और एप्लिकेशन निर्भरताओं को अनुरक्षित रखें। Ubuntu का स्वचालित-अपडेट मार्गदर्शन अनअटेंडेड अपग्रेड, अनुमत ओरिजिन और पुनःआरंभ व्यवहार समझाता है। किसी तृतीय-पक्ष रिपॉज़िटरी को केवल इसलिए स्वतः कवर नहीं माना जाता कि उसे मशीन में जोड़ा गया था। समीक्षा करें कि कॉन्फ़िगर की गई अपडेट प्रक्रिया में वास्तव में क्या शामिल है, और अलग से इंस्टॉल किए गए एप्लिकेशन को उनका अपना रखरखाव मार्ग दें।
तय करें कि सेवा पुनःआरंभ और रीबूट कैसे संभाले जाएँगे। पैकेज अपडेट लागू करने का हमेशा यह अर्थ नहीं होता कि हर चल रही प्रक्रिया नया कोड उपयोग कर रही है। जहाँ वर्कलोड को आवश्यकता हो वहाँ रखरखाव विंडो का उपयोग करें, और बाद में एक सरल एप्लिकेशन जाँच करें। यदि किसी पैकेज को मैन्युअल माइग्रेशन चरण चाहिए, तो उन्हें दस्तावेज़ित करें, न कि सभी अपडेट अनिश्चित काल के लिए बंद करके परिणामी एक्सपोज़र भूल जाएँ।
एप्लिकेशन एक्सेस सीमित करें और रिकवरी की सुरक्षा करें
सेवाओं को उनके आवश्यक अनुमतियों के साथ चलाएँ, और सार्वजनिक सामग्री को सीक्रेट और डिप्लॉयमेंट मेटाडेटा से अलग रखें। किसी वेब प्रक्रिया को हर सिस्टम सेटिंग फिर से लिखने में सक्षम नहीं होना चाहिए। एनवायरनमेंट सीक्रेट को सार्वजनिक रूप से परोसी जाने वाली निर्देशिकाओं के बाहर रखें और उन्हें लॉग, सपोर्ट एक्सपोर्ट या सामान्य बैकअप में बिना किसी जानबूझकर सुरक्षा नीति के शामिल न करें। अप्रयुक्त पैकेज और सेवाएँ हटाएँ जब उनका कोई परिचालन उद्देश्य न हो।
एक स्वतंत्र बैकअप बनाए रखें और एप्लिकेशन को पृथक वातावरण में रिस्टोर करके परीक्षण करें। बैकअप क्रेडेंशियल सीमित करें ताकि कोई समझौता किया गया एप्लिकेशन स्वतः हर रिकवरी प्रति हटा न सके। डिस्क क्षमता, बैकअप आयु और सेवा विफलताओं की निगरानी करें। लॉगिंग को परिभाषित परिचालन प्रश्नों का उत्तर देना चाहिए, जिसमें एक्सेस और रिटेंशन नियंत्रित हों; उसे संवेदनशील अनुरोधों की असीमित प्रति नहीं बनना चाहिए।
पहली डिप्लॉयमेंट का ऐसा क्रम जो समीक्षा-योग्य बना रहे
नए VPS के लिए, पहले एक्सेस और रिकवरी सत्यापित करें, फिर प्रशासनिक खाता और परीक्षित कुंजी स्थापित करें। फ़ायरवॉल कॉन्फ़िगर करें, अपडेट लागू करें और एप्लिकेशन को उसके इच्छित सेवा खाते के अंतर्गत डिप्लॉय करें। किसी अन्य वातावरण से सार्वजनिक व्यवहार की पुष्टि करें, जाँचें कि निजी फ़ाइलें प्राप्त नहीं की जा सकतीं और बैकअप रिस्टोर करें। प्रत्येक निर्णय और एक्सेस परिवर्तन को उलटने के मार्ग के बारे में नोट्स रखें।
Vector VPS, Pulse NVMe और चयनित समर्पित प्लान SwissOctet कैटलॉग में Linux विकल्प प्रस्तुत करते हैं। ऑर्डर करने से पहले चुनी गई इमेज और रखरखाव कार्य के विभाजन की पुष्टि करें। कोई भी Linux इमेज नाम यह सिद्ध नहीं करता कि हार्डनिंग, अपडेट या बैकअप पहले से प्रबंधित हैं। बेसलाइन उन नियंत्रणों का समूह है जिन्हें आप कॉन्फ़िगर, सत्यापित और परियोजना के बदलने के साथ बनाए रखते हैं।
आपकी व्यावहारिक चेकलिस्ट।
- SSH होस्ट की पहचान और रिकवरी मार्ग सत्यापित करें।
- दूसरे सत्र में व्यक्तिगत कुंजी एक्सेस का परीक्षण करें।
- लिसनिंग सेवाओं और फ़ायरवॉल नियमों को सीमित करें।
- अपडेट कवरेज और पुनःआरंभ व्यवहार की समीक्षा करें।
- सीक्रेट को सार्वजनिक फ़ाइलों और सेवा अनुमतियों से अलग करें।
- एक स्वतंत्र रिकवरी प्रति का परीक्षण करें।
महत्वपूर्ण विवरण।
क्या मुझे पासवर्ड लॉगिन तुरंत बंद कर देना चाहिए?+
पहले प्रतिस्थापन कुंजी एक्सेस और रिकवरी मार्ग स्थापित करके परीक्षण करें। फिर अपने समर्थित कॉन्फ़िगरेशन के अनुसार प्रमाणीकरण बदलें।
क्या SSH पोर्ट बदलना हार्डनिंग का विकल्प है?+
नहीं। यह मजबूत प्रमाणीकरण, प्रतिबंधित एक्सेस, अपडेट या उपयुक्त खाता विशेषाधिकार का विकल्प नहीं है।
क्या स्वचालित अपडेट हर एप्लिकेशन के लिए पर्याप्त हैं?+
नहीं। अनुमत रिपॉज़िटरी, पुनःआरंभ आवश्यकताएँ और सिस्टम की अपडेट प्रक्रिया के बाहर इंस्टॉल सॉफ़्टवेयर जाँचें।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- Ubuntu Server: OpenSSH server ubuntu.com
- Ubuntu Server: Firewalls ubuntu.com
- Ubuntu Server: Automatic updates ubuntu.com
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।