व्यवहार में SELinux: DVWA परीक्षण

SELinux के बारे में पिछले लेख के प्रकाशन के बाद, इस सुरक्षा उप-प्रणाली की "उपयोगिता को साबित करने के लिए" कई प्रस्ताव थे। हमने परीक्षण करने का फैसला किया। ऐसा करने के लिए, हमने विशिष्ट कॉन्फ़िगरेशन के साथ तीन संवेदनशील स्टैंड बनाए (सेंटोस 5.8 पर लानत कमजोर वेब एप्लिकेशन)। उनके बीच के अंतर केवल SELinux सेटिंग्स में थे: यह पहली वर्चुअल मशीन पर अक्षम था, अन्य दो पर लक्षित और सख्त नीतियां लागू की गई थीं।

इस संरचना में, प्रवेश के लिए आभासी मशीनों के स्टैंड का परीक्षण किया गया था। परिणामों पर एक नज़र डालें?


हालांकि, चलो पहले नोड्स की सेटिंग्स की ओर मुड़ते हैं। टेम्प्लेट बनाने के लिए, एक "प्रकाश बल्ब" ( LAMP ) के साथ CentOS 5.8 ऑपरेटिंग सिस्टम का उपयोग किया गया था। स्थापित करने की प्रक्रिया में, मैंने इस मामले में सभी संभव विशिष्ट गलतियाँ करने की कोशिश की: सुपरसुअर अधिकारों के साथ डेटाबेस से जुड़ना, डिफ़ॉल्ट रूप से सब कुछ सेट करना। इस प्रकार, हमने एक ही शुरुआती बिंदु के साथ घटनाओं के विकास की तीन पंक्तियों को फिर से बनाने की कोशिश की।

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

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

वेब सर्वर को सुरक्षित करने के विकल्पों में से एक के रूप में, मैंने एक लक्षित नीति के साथ SELinux का उपयोग किया। मैंने इसमें कोई परिवर्तन नहीं किया: समाधान "आउट ऑफ द बॉक्स" ठीक उसी रूप में है जिसमें विक्रेता इसे प्रस्तुत करता है। सेवाएं रेडी हैट इंजीनियरों के दृष्टिकोण से तैयार डोमेन में चलती हैं और "मानक संचालन" के ढांचे के भीतर काम करती हैं।

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

मैंने पॉजिटिव टेक्नॉलॉजीज से अपने सहकर्मी से पूछा (हेबर पर इसे ki11obyte के रूप में जाना जाता है) ने एक पैठ परीक्षण किया। वह बताता रहेगा।

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

सर्वर पर छवियों को अपलोड करने के एक रूप को देखते हुए, जो केवल अनुरोध में सामग्री-प्रकार फ़ील्ड की जांच करता है। हम PHP में वेब शेल भरते हैं, सामग्री / प्रकार (इस मामले में BurpSuite का उपयोग करके) की जगह छवि / जेपीईजी के साथ।



शेल परीक्षण पास करता है और सर्वर पर अपलोड किया जाता है।



कॉन्फ़िगर किया हुआ SELinux भी इस मामले में सिस्टम की सुरक्षा करने में असमर्थ था।

अगला, आपको एक वेब शेल चलाने की आवश्यकता है। ऐसा करने के लिए, हमें अन्य स्क्रिप्ट डाउनलोड करने की क्षमता के साथ साइट पर एक कमजोर स्क्रिप्ट मिलती है।



प्रत्येक मशीन पर फ़ाइल सफलतापूर्वक जुड़ी हुई है। इसलिए, SELinux, वेब अनुप्रयोगों में त्रुटियों से हमारी रक्षा नहीं करेगा।

अब हम लोड किए गए वेब शेल के माध्यम से कमांड को सुरक्षित रूप से निष्पादित कर सकते हैं।



या हम एक अधिक परिचित कंसोल प्राप्त करने के लिए रिवर्स कनेक्शन का उपयोग कर सकते हैं।



अब SELinux वाली मशीन की कतार सक्षम है। हमें वेब शेल फिर से मिलता है - और थोड़ा निराश: सॉकेट बनाने और यहां तक ​​कि एलएस निष्पादित करने के लिए पर्याप्त अधिकार नहीं हैं।





हालांकि, निर्देशिकाओं को सूचीबद्ध करने की क्षमता की कमी के बावजूद, हम आसानी से फ़ाइलों को ब्राउज़ कर सकते हैं।



लिस्टिंग, वैसे, PHP का उपयोग करके लागू किया गया था।



इसके अलावा, एक फ़ाइल बनाना, इसे निष्पादन योग्य बनाना और निष्पादित करना संभव था।



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

एक का चयन करें LOAD_FILE क्वेरी ('/ etc / passwd') आपको फ़ाइलों को पढ़ने की अनुमति देता है। हम फ़ाइल को एक अस्थायी निर्देशिका में भी आसानी से लिख सकते हैं: 1 INTO OUTFILE '/ tmp / ololo' का चयन करें। क्या वास्तव में अजीब निकला, बनाई गई फ़ाइल के बजाय असामान्य अधिकार हैं।




SELinux वाली मशीन को चालू किया और कॉन्फ़िगर किया गया, कोई अंतर नहीं पाया गया, जो कुछ हद तक निराश था।
-

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

दूसरे, यह पूरी तरह से स्पष्ट हो गया कि वेब प्रोजेक्ट के लिए SELinux की स्थापना एक बहुत ही समय लेने वाला कार्य है जिसके लिए मजबूत ज्ञान और काफी प्रयास की आवश्यकता होती है। मैं ध्यान देता हूं: न केवल "वेब सर्वर की सुरक्षा के लिए", बल्कि इस परियोजना को पूरी तरह से संरक्षित करने के लिए। अपनी स्वयं की संदर्भ सहभागिता नीति बनाना संभव है, लेकिन इस बात की आशंका संदिग्ध है। मेरी व्यक्तिगत राय: बहुत अधिक php और httpd के उचित विन्यास और नियमित अपडेट पर निर्भर करता है।

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