APAC प्रणालियों के लिए लिनक्स इन्फ्रास्ट्रक्चर हार्डनिंग

विषय सूची

उत्पादन में अधिकांश लिनक्स सिस्टम अपने डिफ़ॉल्ट कॉन्फ़िगरेशन के बहुत करीब चलते हैं, जितना कि कोई भी स्वीकार करना चाहेगा। हार्डनिंग दस्तावेज़ किसी पुरानी ऑडिट फ़ाइल में मौजूद होते हैं, लेकिन वास्तविक सर्वर उनसे मेल नहीं खाते। “दस्तावेजी बेसलाइन” और “वास्तविक कॉन्फ़िगरेशन” के बीच का यह अंतर वही स्थान है जहाँ हमलावर आसानी से अपनी जगह बना लेते हैं।

लिनक्स हार्डनिंग उस अंतर को बंद करने का इंजीनियरिंग अनुशासन है, और इसे इस तरह से करना है जो अगले डिप्लॉयमेंट के बाद भी टिका रहे।

डिफ़ॉल्ट सेटिंग्स संगतता को प्राथमिकता देती हैं, सुरक्षा को नहीं #

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

मुख्य कार्य कुछ प्रमुख श्रेणियों में आता है:

कर्नेल और sysctl ट्यूनिंग: नेटवर्क सुरक्षा (जैसे ICMP रीडायरेक्ट्स को अनदेखा करना, रिवर्स-पाथ फ़िल्टरिंग सक्षम करना), फ़ाइल सिस्टम प्रतिबंध, और ASLR (एड्रेस स्पेस लेआउट रैंडमाइजेशन) जैसी मेमोरी सुरक्षा।
सेवाओं का न्यूनीकरण: उन सभी सेवाओं और पैकेजों को अक्षम और हटाना जिन्हें होस्ट नहीं चलाता, ताकि शोषण के लिए कोई अप्रयुक्त घटक न बचे।
अनिवार्य एक्सेस कंट्रोल (MAC): किसी प्रक्रिया द्वारा क्या किया जा सकता है इसे सीमित करने के लिए SELinux या AppArmor, भले ही वह प्रक्रिया प्रभावित क्यों न हो गई हो।
Systemd और कंटेनर हार्डनिंग: लिनक्स क्षमताओं (capabilities) को छोड़ना, रॉ सॉकेट एक्सेस को ब्लॉक करना, और seccomp प्रोफाइल के साथ सिस्टम कॉल को प्रतिबंधित करना।
ऑडिट और लॉगिंग: महत्वपूर्ण घटनाओं को कैप्चर करना और उन्हें होस्ट से बाहर केंद्रीय सर्वर पर भेजना ताकि हमलावर अपने पैरों के निशान न मिटा सके।

CIS बेंचमार्क (CIS Benchmarks) इन नियंत्रणों के सबसे व्यावहारिक और व्यापक रूप से मान्यता प्राप्त मानक बने हुए हैं, और OpenSCAP इन्हें लागू करने और ऑडिट करने दोनों को स्वचालित करता है।

कॉन्फ़िगरेशन कोड के रूप में है, अन्यथा इसका कोई अस्तित्व नहीं है #

विकी पर मौजूद हार्डनिंग गाइड केवल एक इच्छा सूची है। कोड में मौजूद हार्डनिंग (जैसे Ansible रोल, Packer इमेज, Kubernetes एडमिशन पॉलिसी) एक ठोस वास्तविकता है। जब बेसलाइन कोड होती है, तो तीन चीजें बदल जाती हैं:

यह पुनरुत्पादन योग्य (reproducible) है। प्रत्येक नया होस्ट बेसलाइन विरासत में प्राप्त करता है, न कि केवल वही जिन्हें कोई कॉन्फ़िगर करना याद रखता है।
यह परीक्षण योग्य है। CI/CD में एक अनुपालन स्कैन बिल्ड को विफल कर देता है जब कोई सेटिंग विचलित होती है।
यह समीक्षा योग्य है। बेसलाइन में बदलाव एक पुल रिक्वेस्ट (Pull Request) होता है, जिसमें एप्लिकेशन कोड के समान समीक्षा अनुशासन होता है।

यह वार्षिक औपचारिकता के रूप में हार्डनिंग और प्लेटफ़ॉर्म की एक स्थायी विशेषता के रूप में हार्डनिंग के बीच का वास्तविक अंतर है।

अंतिम लक्ष्य: अपरिवर्तनीय इन्फ्रास्ट्रक्चर (Immutable Infrastructure) #

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

अपरिवर्तनीय इन्फ्रास्ट्रक्चर स्वाभाविक रूप से हार्डनिंग-ऐज़-कोड के साथ जुड़ता है। आप किसी बेसलाइन का रखरखाव नहीं कर रहे हैं; आप इमेज में ही सुरक्षा को संकलित कर रहे हैं। और जब कोई भेद्यता सामने आती है, तो समाधान आधी रात का SSH सत्र नहीं बल्कि एक नया रीबिल्ड होता है।

flowchart LR A[CIS बेंचमार्क कोड के रूप में] --> B[CI में हार्डन इमेज बिल्ड] B --> C[पाइपलाइन में अनुपालन स्कैन] C -- पास --> D[तैनाती और इंस्टेंस रोटेशन] C -- फेल --> B style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px

होस्ट से आगे #

हार्डनिंग ऑपरेटिंग सिस्टम पर समाप्त नहीं होती। वही अनुशासन कई दिशाओं में बाहर की ओर फैलता है, जिनमें से प्रत्येक के अपने विफलता मोड होते हैं।

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

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

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

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

निश्चित नहीं हैं कि आपके सर्वर वास्तव में आपके हार्डनिंग दस्तावेज़ों से मेल खाते हैं या नहीं? सीधी तकनीकी समीक्षा के लिए संपर्क करें: ईमेल (hello@puresecurity.com) या LINE (@PureSecurity)।

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