मुझे एक सत्र के लिए एक वेबसाइट पर कई आईपी पते की अनुमति क्यों देनी चाहिए?

Question

मुझे उम्मीद है कि मेरा प्रश्न इस साइट के दायरे से मेल खाता है।

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

मुझे आश्चर्य है कि, मेरे ग्राहकों को एक पृष्ठ अनुरोध के लिए आईपी पते के बीच लगातार कूदने की अनुमति देने में क्या जोखिम हैं (उदाहरण के लिए, CSS फाइलें xxx.xxx.xxx.xxx द्वारा अनुरोध की गई हैं और जावास्क्रिप्ट फाइलें yyy.yy.yyy द्वारा अनुरोध की गई हैं। yyy)? क्या मुझे आमतौर पर अनुमति देनी चाहिए या उस पर प्रतिबंध लगाना चाहिए?

Comments

IPs के चारों ओर कूदने के लिए आपको लोड बैलेंसरों की भी आवश्यकता नहीं है। सबवे पर अपने फोन से कनेक्ट करें, आपको ट्रेन यात्रा के दौरान हर कुछ मिनटों में एक अलग आईपी मिल सकता है, और फिर जब आपका फोन गंतव्य पर वाईफाई पर स्विच करता है।

— whatsisname

स्थानों (कहो, घर> काम> स्टारबक्स) के बीच चलने वाले लैपटॉप के लिए भी। इसके अलावा: IPv6 यादृच्छिक पते (IPv6 SLAAC गोपनीयता एक्सटेंशन)।

— मार्सेल

सहजता से, मैं उम्मीद करूँगा कि ग्राहक अलग-अलग स्रोत Ips पर कूदते हुए समस्याएँ पैदा करें यदि यह "कभी-कभार" से अधिक कुछ भी हो।

— टॉम एच

यदि आप एक वेबऐप विकसित कर रहे हैं जो एक नेटवर्क में स्थापित किया जाएगा जिसे आप नियंत्रित करते हैं या आपको इसका ज्ञान है तो आप सुरक्षा के लिए ऐसा करने का निर्णय ले सकते हैं क्योंकि आप यह कहने में सक्षम हो सकते हैं "इस स्थिति में कई आईपी ऐसा नहीं होने जा रहे हैं जब से उपयोगकर्ताओं को होना चाहिए अपने WS से इसे एक्सेस करें और इसके बीच में कोई लोड बैलेंसर या अन्य सामान न हो जिससे उनका IP बदल जाए "... उस स्थिति में आप उपयोगकर्ताओं के IP को ट्रैक करने में सक्षम हो सकते हैं क्योंकि उनके WS में हमेशा एक ही (या हो सकता है) हर महीने में केवल एक बार बदलाव हो सकता है)

— बाकूरी

@TomH नहीं, अधिकांश वेबपेज आपके आईपी पते की परवाह नहीं करते हैं, वे एक नए टीसीपी कनेक्शन पर HTTP अनुरोध में समान कुकीज़ स्वीकार करेंगे। केवल ख़राब और बुरी तरह से डिज़ाइन की गई बकवास आपके सत्र को IP या कनेक्शन से लॉक कर देती है।

— नविन

Answer 1

मेरे उपयोगकर्ताबेस का एक छोटा हिस्सा लगातार दो या अधिक आईपी पतों के बीच कूदता है।

कारण

यह मानते हुए कि आपके उपयोगकर्ता सक्रिय रूप से अज्ञात सेवा का उपयोग करके अपने वास्तविक आईपी पते को छिपाने की कोशिश नहीं कर रहे हैं ...:

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

आप डुअल स्टैक उपयोगकर्ताओं को IPv4 और IPv6 पर अनुरोध करने और बाद के अनुरोधों के लिए दो प्रोटोकॉल RFC 8305 के बीच स्विच करने को देख सकते हैं ।

अन्य परिदृश्य तब है जब मैं वाई-फाई एक्सेस प्वाइंट की चरम सीमा पर हूं और मेरा डिवाइस वाई-फाई और सेल्युलर डेटा के बीच "बेतरतीब ढंग से" स्विच करता है।

समाधान

पहले परिदृश्य में आप केवल पहले तीन ऑक्टेट पर विचार करके अपने सत्रों में इस तरह के आईपी पते "सुरक्षा" को रखने पर समझौता कर सकते हैं, क्योंकि आमतौर पर प्रॉक्सी सर्वर का ऐसा क्लस्टर एक छोटे सबनेट के भीतर होता है और इसमें पड़ोसी आईपी पते होंगे।

दूसरे और तीसरे परिदृश्य में आप असंबंधित प्रदाताओं से भी पूरी तरह से अलग ग्राहक आईपी पते देखेंगे।

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

Comments

कोई भी आईपी पते के लिए सत्रों को जोड़ता नहीं है, ठीक इन कारणों से।

— माइकल हैम्पटन

कभी आईपी-पतों के लिए सत्र टाई, 80 के दशक खत्म हो गए हैं! मेरा आईएसपी मेरे फोन को एक पूर्ण / 64 नेटवर्क की आपूर्ति करता है जिसमें मेरा ब्राउज़र पागल की तरह कूदता है।

— ब्योस्टर

सभी के अलावा, मल्टीपाथ टीसीपी तेजी से सामान्य हो रहा है।

— Can Poyrazoğlu

यदि आप तकनीकी उपयोगकर्ताओं के लिए अपना सीएमएस बना रहे हैं, तो आप लॉगिन पृष्ठ पर "इस सत्र को अपने आईपी (xxx.yyy.zzz.iii) केवल" चेकबॉक्स तक सीमित कर सकते हैं

— फेरीबग

@bjoster कि IPv6 गोपनीयता एक्सटेंशन के कारण, यह पते को स्विच करता रहता है, इसलिए वेबसाइटें आपको आपके आईपी द्वारा अकेले ट्रैक नहीं कर सकती हैं (यह IPv4 के साथ कोई समस्या नहीं है, क्योंकि कई लोग एक ही पते के पीछे हैं)

— Ferrybig

Answer 2

मुझे आश्चर्य है कि, मेरे ग्राहकों को एक पृष्ठ अनुरोध के लिए आईपी पते के बीच लगातार कूदने की अनुमति देने में क्या जोखिम हैं (उदाहरण के लिए, CSS फाइलें xxx.xxx.xxx.xxx द्वारा अनुरोध की गई हैं और जावास्क्रिप्ट फाइलें yyy.yy.yyy द्वारा अनुरोध की गई हैं। yyy)? क्या मुझे आमतौर पर अनुमति देनी चाहिए या उस पर प्रतिबंध लगाना चाहिए?

प्राथमिक जोखिम एक दुर्भावनापूर्ण उपयोगकर्ता है जो सत्र का अपहरण कर रहा है। यदि आप IP पते के एक या एक छोटे सेट पर लॉक कर सकते हैं, तो आप सत्र को हाइजैक करने से उपयोगकर्ताओं को पूरी तरह से अलग IP पते से ब्लॉक कर सकते हैं।

समस्या यह है कि कुछ उपयोगकर्ता वैध तरीके से ऐसा करते हैं। चाहे वे लोड संतुलित प्रॉक्सी का उपयोग कर रहे हों या दो वायरलेस एक्सेस पॉइंट (या जो भी) के मार्जिन पर हों, वे कई आईपी एड्रेस का उपयोग करते हैं। तो आप बहुत ज्यादा उन उपयोगकर्ताओं के लिए अनुमति देने के लिए है। और यह बताना मुश्किल है कि किन उपयोगकर्ताओं को एकाधिक आईपी पते की आवश्यकता होती है, जब वे कई आईपी पते से अनुरोध करते हैं।

इसका प्रभाव कम करने का एक तरीका HTTPS का उपयोग करना है। फिर दुर्भावनापूर्ण अभिनेता के पास सुरक्षित कुकी के साथ-साथ सत्र कुकी से समझौता करने का एक तरीका है। असुरक्षित कनेक्शन पर, दुर्भावनापूर्ण अभिनेता सत्र कुकी से समझौता करने के लिए नेटवर्क निरीक्षण का उपयोग कर सकता है। लेकिन HTTPS के दौरान, एक ही दुर्भावनापूर्ण अभिनेता को वार्तालाप के किसी एक छोर तक पहुंच की आवश्यकता होती है। और अगर दुर्भावनापूर्ण अभिनेता के पास ऐसा है, तो एक अलग आईपी का उपयोग करना आवश्यक नहीं है।

TL; DR : आपको आम तौर पर एक ही उपयोगकर्ता के लिए अलग-अलग आईपी पते से अनुरोधों की अनुमति देनी चाहिए। इसके वैध कारण हो सकते हैं। उस श्रेणी के कारनामों से बचाने के लिए HTTPS का उपयोग करें।

Answer 3

मेरे ग्राहकों को पेज अनुरोध के लिए आईपी पते के बीच लगातार कूदने की अनुमति देने में क्या जोखिम हैं

एक सुरक्षा दृष्टिकोण से - शून्य जोखिम।

अब, एक व्यावहारिक दृष्टिकोण से। इसका मतलब है कि आप सुरक्षा या DoS सुरक्षा के लिए कुछ प्रकार के एल्गोरिदम का उपयोग नहीं कर सकते ।

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

संबंधित, लेकिन अलग-अलग, उपयोग-मामला थ्रॉटलिंग विफल लॉगिन प्रयास है। यह ब्रूट-फोर्स पासवर्ड अनुमान लगाने से रोकना है। लेकिन फिर भी, कुछ भी नहीं है जो आप कर सकते हैं अगर उपयोगकर्ता आईपी पते बदलते हैं। एक वास्तव में गंभीर हैकर भी अपनी मशीनों का उपयोग नहीं करेगा। वह बस एक बोटनेट पर कुछ समय खरीदता है (या अपने पहले से संक्रमित बोटनेट का उपयोग करता है) और 10,000 अन्य लोगों के पीसी (आईपी पते) के माध्यम से आपकी सेवा से जुड़ सकता है। यह वास्तव में उपयोगकर्ता के आईपी पते को सीमित करने से संबंधित नहीं है क्योंकि यह पूर्व-लॉगिन है, लेकिन यह ध्यान में रखने के लिए कुछ है।

Answer 4

उपयोगकर्ता के नए IP पते पर जाने के कई कारण हो सकते हैं।

1. IPv6 गोपनीयता एक्सटेंशन, कई IPv6 ग्राहक आजकल लेन पर / 64 के भीतर कूद जाएंगे।
2. संतुलित परदे के पीछे लोड, ग्राहकों का अनुरोध एक अलग आईपी के साथ कई परदे के पीछे से एक के लिए मार्ग दिया जाता है।
3. NAT पूल, बॉर्डर नैट को कई आईपी एड्रेस से कॉन्फ़िगर किया गया है और पूल आर्बिटरी से क्लाइंट टीसीपी कनेक्शन के लिए आईपी / पोर्ट संयोजन प्रदान करता है।
4. उपयोगकर्ता अलग-अलग नेटवर्क या नेटवर्क के कुछ हिस्सों के बीच चलता है, आजकल फोन के साथ आम है।
5. दोहरी स्टैक उपयोगकर्ता IPv4 और IPv6 के बीच आशा कर सकते हैं।

मुझे आश्चर्य है कि, मेरे ग्राहकों को पेज अनुरोध के लिए आईपी के बीच लगातार कूदने की अनुमति देने में क्या जोखिम हैं

ग्राहक sessoins को IP पर लॉक करने का फायदा यह है कि इससे सत्र चोरी के हमलों को मुश्किल हो जाता है। यदि किसी हमलावर के पास एक ऐसा तंत्र है जो उन्हें क्लाइंट कुकीज़ चुराने देता है, लेकिन उन्हें क्लाइंट के आईपी पते से आपके सर्वर से कनेक्शन नहीं करने देता है तो आईपी लॉक उन्हें सत्र चोरी करने से रोक देगा।

नकारात्मक पक्ष यह है कि जैसा कि आप कहते हैं कि यह कुछ उपयोगकर्ताओं के लिए टूट-फूट का कारण बनेगा जो बिना किसी स्पष्ट कारण के अपने सत्र को अमान्य मानते हैं।

आजकल ज्यादातर साइटों को लगता है कि ब्रेक्जिट इस तरह के लॉकिंग के लाभों से आगे निकल जाता है।