लोड बैलेंसर और वास्तविक आईपी संबंध आपकी सुरक्षा को कैसे जोखिम में डालते हैं?

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

प्रॉक्सी और रियल आईपी कॉन्सेप्ट

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

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

एक्स-फॉरवर्ड-फॉर एंड आईपी रिलेशनशिप

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

चूँकि इसका IP पता पूरी विकास प्रक्रिया के दौरान तय किया जाएगा, यह परीक्षणों के दौरान हमेशा एक ही पता देखेगा क्योंकि आम तौर पर, उपयोगकर्ता कंप्यूटर में कॉर्पोरेट नेटवर्क स्टेटिक आईपी के साथ काम करते हैं मैक पते पर। इकाई कुछ स्वीकृति परीक्षण करेगी; हालाँकि, इनके साथ समस्याएँ होंगी। परीक्षण इकाई इस समस्या को सॉफ़्टवेयर डेवलपर को अग्रेषित करेगी।

इस स्तर पर, डेवलपर विकास के वातावरण में एक नियंत्रक लिख सकता है और HTTP अनुरोध को कच्चे रूप में प्रेषित कर सकता है, क्योंकि सभी के पास एक ही आईपी पता है। इसका परिणाम एक्स-फॉरवर्डेड-फॉर के साथ काम करना होगा।

शीर्षलेख जानकारी एक्स-फॉरवर्डेड-फॉर नामक एप्लिकेशन सर्वर को भेजा जाएगा। इस स्तर पर, सॉफ़्टवेयर डेवलपर अपना IP पता देखेंगे, जिसे वे ipconfig से नियंत्रित करते हैं, न कि लोड बैलेंसर को जो वे लॉग में देखते हैं। कई प्रोग्रामर सोचते हैं कि वे इस समस्या को कोड ब्लॉक के साथ इस तरह हल कर सकते हैं:

समारोहgetIaddress() {
 $ipKeys = सरणी(
'HTTP_CLIENT_IP', 
'HTTP_X_FORWARDED_FOR', 
'HTTP_X_FORWARDED', 
'HTTP_X_CLUSTER_CLIENT_IP', 
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED', 
'REMOTE_ADDR'
);
प्रत्येक के लिए ($ipKeys जैसा $कुंजी) {
अगर (array_key_exists ($ कुंजी, $ _ सर्वर) सत्य) {
प्रत्येक के लिए (विस्फोट(',', $_SERVER[$कुंजी]) जैसा $ आईपी) {
 $ आईपी = ट्रिम ($ आईपी);
अगर (Validate_ip($ip)) {
वापस करना $ आईपी;
 }
 }
 }
 }
वापस करनाisset($ _ सर्वर ['REMOTE_ADDR'])? $_सर्वर['REMOTE_ADDR']: असत्य;
}

यह पर्याप्त नहीं होगा - डेवलपर को यह जांचने की आवश्यकता है कि आने वाला मूल्य एक वैध आईपी पता है या नहीं।

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

सिस्टम प्रशासक सोच सकते हैं कि डेवलपर्स एक्स-फॉरवर्डेड-फॉर जैसी जानकारी रिकॉर्ड करते हैं क्योंकि HTTP अनुरोध में डेटा पर भरोसा नहीं किया जा सकता है। वे प्रशासक अक्सर एक्स-फॉरवर्डेड-फॉर; हालाँकि, वे उस सिस्टम के टीसीपी स्रोत पते को भी प्रसारित करते हैं जिसने अनुरोध को दूसरे हेडर मान के रूप में भेजा था। ट्रू-क्लाइंट-आईपी संरचना इसका एक अच्छा उदाहरण है।

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

पेनेट्रेशन टेस्ट में क्लाइंट आईपी स्पूफिंग का पता कैसे लगाया जाता है?

अधिकांश पैठ परीक्षक अपनी सुरक्षा जांच के लिए फ़ायरफ़ॉक्स का उपयोग करते हैं। वे फ़ायरफ़ॉक्स को सभी HTTP अनुरोधों के लिए एक साधारण ऐड-ऑन, X-Forwarded-For: 127.0.0.1 के साथ कॉन्फ़िगर करते हैं। और इसलिए, सभी पैठ परीक्षणों में ऐसी कमजोरियों का पता लगाने की संभावना बढ़ जाती है। के अनुसार लेखापरीक्षा करना OWASP चेकलिस्ट सुनिश्चित करता है कि आप ऐसी कमजोरियों की जाँच करें। हालाँकि, एक्स-फॉरवर्डेड-फॉर भेद्यता का पता लगाने के लिए, आपको एप्लिकेशन में एक मॉड्यूल की आवश्यकता होती है जो आपके आईपी पते या की गई कार्रवाइयों को दिखाता है।

एक्स-फॉरवर्डेड-फॉर वल्नरेबिलिटी को कैसे हल करें

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

लेकिन इस समस्या को हल करने के लिए, आप निम्न F5 नियम का उपयोग कर सकते हैं:

जब HTTP_REQUEST {
 HTTP:: हेडर एक्स-फॉरवर्डेड को हटा दें-के लिए
 HTTP:: हैडर इन्सर्ट एक्स-फॉरवर्डेड-के लिए [आईपी:: Remote_addr]
}

यह बाहरी दुनिया से HTTP अनुरोध में X-Forwarded-For फ़ील्ड को हटा देता है। फिर यह अनुरोध भेजने वाले सिस्टम के आईपी पते को जोड़कर अनुरोध को प्रसारित करता है। इस प्रकार, सॉफ़्टवेयर के लिए एक विश्वसनीय सूची बनाई जाती है जो X-Forwarded-For के अनुसार कार्य करती है।

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

साइबर सुरक्षा फ्रेमवर्क और उद्यमों के लिए प्रलेखन

जो इकाइयाँ एक-दूसरे से स्वतंत्र प्रतीत होती हैं, वे वास्तव में एक संपूर्ण का भाग होती हैं। इसलिए सब कुछ व्यवस्थित रूप से काम करना है। पहले से निर्धारित नियमों को प्रत्येक इकाई के बीच लागू किया जाना चाहिए। यदि इस तरह की कार्य प्रणाली को नहीं अपनाया जाता है, तो एक्स-फॉरवर्डेड-फॉर भेद्यता जैसी कई समस्याएं हो सकती हैं। इसके लिए, सब कुछ पहले से ही विचार किया जाना चाहिए और यथासंभव व्यापक प्रलेखन का उपयोग किया जाना चाहिए।

और इस बड़ी प्रणाली की हर इकाई को साइबर सुरक्षा ढांचे को अपनाने और लागू करने की जरूरत है। आपका प्रारंभिक बिंदु इन रूपरेखाओं के कार्य तर्क को अनुसंधान और सीखना होना चाहिए।