2012-02-17 8 views
5

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

मेरी चिंता यह है कि जावा सर्वलेट में किसी ग्राहक के आईपी पते को सटीक रूप से निर्धारित करना संभव है? क्या यह संभव है कि आईपी जो मुझे सर्वलेट में मिलता है, कुछ हैकिंग तंत्र द्वारा बदला जा सकता है ताकि मेरा सर्वर यह मान सके कि यह विश्वसनीय आईपी है?

उदाहरण के लिए यदि मेरी सर्वर मशीन को 192.168.0.1 पर भरोसा करने के लिए कॉन्फ़िगर किया गया है, तो क्या यह 1 9 2.168.0.1 के अलावा किसी अन्य क्लाइंट द्वारा 192.168.0.1 के रूप में नाटक करने और मेरे प्रमाणीकरण तंत्र को मूर्ख बनाने के लिए संभव है?

उत्तर

14

आप आईपी पता प्राप्त करने के लिए HttpServletRequest कक्षा से getRemoteAddr() विधि का उपयोग कर सकते हैं। हालांकि सावधान रहें। यदि आपका ग्राहक प्रॉक्सी सर्वर (या यहां तक ​​कि एक नेटिंग फ़ायरवॉल) के पीछे है, तो आपको इसके बजाय प्रॉक्सी आईपी पता मिलेगा।

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

लेकिन ध्यान रखें कि स्रोत आईपी पते को किसी भी दुर्भावनापूर्ण ग्राहक द्वारा आसानी से बदला या फिक्र किया जा सकता है। मैं वास्तव में कुछ प्रकार के क्लाइंट प्रमाणीकरण (उदाहरण के लिए एक प्रमाण पत्र) का उपयोग करने की सलाह देते हैं। वेब ऐप के लिए सटीक क्लाइंट आईपी पता निर्धारित करने का कोई तरीका नहीं है।

+0

और एक्सएफएफ हेडर का उल्लेख करने के लिए +1 और शून्य के लिए संभावना – stevevls

+0

क्लाइंट प्रमाणीकरण कैसे काम करता है? क्या ग्राहक स्वयं को पहचानने के लिए https संचार में जो सर्वर भेजता है, उसके समान प्रमाण पत्र भेज सकता है, क्या आप कृपया इस पर कुछ विवरण प्रदान कर सकते हैं। – Ashish

+1

आप एक स्व-हस्ताक्षरित क्लाइंट प्रमाणपत्र उत्पन्न कर सकते हैं और इसे अपने क्लाइंट मशीन की कीस्टोर पर स्थापित कर सकते हैं (क्या आप अपने क्लाइंट में जावा का भी उपयोग कर रहे हैं?)। फिर, आपके सर्वर को केवल किसी दिए गए सीए (स्वयं, इस मामले में) से क्लाइंट प्रमाणपत्रों द्वारा हस्ताक्षरित अनुरोध स्वीकार करना चाहिए। वेब पर जावा + क्लाइंट प्रमाणपत्रों के संबंध में बहुत सारे दस्तावेज हैं। साथ ही, बुनियादी बातों के लिए टीएलएस पर उत्कृष्ट [विकिपीडिया एंट्री] (http://en.wikipedia.org/wiki/Transport_Layer_Security) पर एक नज़र डालें। पढ़ने बनाम लिखने के प्रभाव लाने के लिए – Viccari

0

आईपी आसानी से ईमेल प्रेषकों की तरह फिक्र किया जा सकता है, मैं दृढ़ता से सुझाव देता हूं कि वे पूरी तरह से उन पर भरोसा न करें।

+0

मेल प्रेषक के रूप में उतना आसान नहीं है, जैसा कि आप निर्दिष्ट आईपी पते का जवाब देते हैं। तो असली समस्या कार्रवाई के मामले में स्रोत आईपी tzrusting है, लेकिन आप जानकारी प्रदान करते समय उन पर भरोसा कर सकते हैं – Hurda

+1

हाँ, मैं stevelvs जवाब upvoted क्योंकि वह लिखने और पढ़ने के बीच भेद बनाता है। Btw। मेल प्रेषक बिल्कुल वही है क्योंकि आप दोनों मामलों में जवाब प्राप्त नहीं कर सकते हैं। – wintersolutions

7

आपकी सेवा IP Spoofing के लिए कमजोर हो सकती है। एक अलग आईपी पते से होने वाले पैकेट को बनाना आसान है। हालांकि, स्पूफिंग के बारे में बात यह है कि हमलावर कोई प्रतिक्रिया पैकेट प्राप्त नहीं कर पाएगा। इसलिए, यदि आपकी सेवाओं को कॉल करने से राज्य का आंतरिक परिवर्तन नहीं होता है (यानी यह केवल पढ़ता है), तो आपको ठीक होना चाहिए। यदि, हालांकि, आपकी सेवा के लिए कॉल लिखेंगे, तो आपको केवल आईपी पते पर भरोसा नहीं करना चाहिए क्योंकि एक स्पूफ़ेड पैकेट आपके सिस्टम की आंतरिक स्थिति को बदलने के लिए पर्याप्त होगा।

+0

+1। – Viccari

+0

क्या आप कृपया कुछ तरीका प्रदान कर सकते हैं कि मैं वांछित कार्यक्षमता कैसे प्राप्त कर सकता हूं यानी मेरे नेटवर्क में एक मशीन पर भरोसा कर सकता हूं। – Ashish

+0

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

2

आप ARP Spoofing पर स्थानीय रूप से संदिग्ध हो सकते हैं। जहां एक दुर्भावनापूर्ण मशीन आईपी पते को अपने मैक पते से जोड़ने के लिए राउटर को आश्वस्त करती है।

स्तर और विश्वास की व्यवस्था वास्तव में सर्वर/सेवा और पर्यावरण आप में काम कर रहे हैं आप को बचाने की कोशिश कर रहे हैं की संवेदनशीलता पर निर्भर करता है।

यह मेरे लिए लग रहा है कि यह एक स्थानीय व्यवस्था निजी दिया है आईपी ​​पता 192.168 रेंज। यदि यह सर्वर सार्वजनिक नहीं है, तो महत्वपूर्ण नहीं है और आप अपेक्षाकृत सुरक्षित लैन वातावरण में परिचालन कर रहे हैं जो सार्वजनिक और अन्य निजी LANS से ​​अच्छी तरह से बंद है, तो आपको ठीक होना चाहिए। अन्यथा आपको उच्च स्तर पर अन्य सुरक्षा विकल्पों को देखना चाहिए।

+0

अच्छा बिंदु। मैंने स्थानीय नेटवर्क पर दुर्भावनापूर्ण उपयोगकर्ताओं के बारे में चिंता करने में काफी समय नहीं लगाया है, हालांकि यह निश्चित रूप से होने के लिए जाना जाता है और इसके खिलाफ सुरक्षा के लिए एक अच्छा विचार है। :) – stevevls

+0

1 9 2.168 आईपी रेंज किसी भी सार्वजनिक राउटर द्वारा नहीं की जाएगी। तो किसी भी खतरे को आंतरिक रूप से आना होगा –

1

मेरी चिंता यह है कि जावा सर्वलेट में किसी ग्राहक के आईपी पते को सटीक रूप से निर्धारित करना संभव है?

नहीं, यह संभव नहीं है। ऐसे कई परिदृश्य हैं जहां उपयोगकर्ता के कार्यों या उपयोगकर्ता के नियंत्रण के बाहर होने वाले अन्य कारणों के कारण आपको वास्तविक क्लाइंट आईपी पता नहीं दिखाई देगा।

बाद के मामलों में, आईपी-आधारित पहचान आपके ईमानदार ग्राहकों के लिए सिर-दर्द पैदा करती है; यानी वे ग्राहक जिन्हें आप वास्तव में रखना चाहते हैं।

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