साझा VPN एग्ज़िट उन लॉगिन चेतावनियों को क्यों जगाता है जो आपने पैदा नहीं कीं
लॉगिन ब्लॉक आमतौर पर एक जोखिम स्कोर होता है, आपके टनल पर फैसला नहीं। साझा एग्ज़िट बदलते हैं कि उस स्कोर में और कौन शामिल है और उन्हें इसकी क्या कीमत चुकानी पड़ती है।
किसी जानी-पहचानी साइट को VPN से खोलिए और एक अतिरिक्त चुनौती मिलिए, तो लुभावना स्पष्टीकरण यह है कि टनल पकड़ा गया। कुछ पकड़ा गया, पर वह आप नहीं थे। साइट ने कई संकेतों का स्कोर बनाया, जिनमें एक स्रोत पता है, और वह पता उन अजनबियों के साथ साझा है जो एक मिनट पहले असफल लॉगिन पैदा कर रहे होंगे। इस निर्णय को अपने कनेक्शन पर फैसला मानकर पढ़ना यह गलत समझना है कि स्कोर किसलिए है।
स्रोत पता क्या तय कर सकता है और क्या नहीं
IP पता किसी क्षण नेटवर्क से गुजरने वाले रास्ते का वर्णन करता है। यह किसी व्यक्ति, डिवाइस या एक भी खाते की पहचान नहीं करता, और कैरियर-ग्रेड NAT या व्यस्त VPN पूल के साथ यह एक साथ हज़ारों असंबंधित सत्रों के सामने हो सकता है। जो साइट पते को पहचान मानती है, वह वास्तव में उसे प्रतिष्ठा मानती है, जो एक सांख्यिकीय कथन है, तथ्य नहीं।
दो लोग एक ही एग्ज़िट साझा करके विपरीत सबूत दे सकते हैं: एक दूसरे कारक के साथ सफलतापूर्वक साइन इन करता है, दूसरा चालीस पासवर्ड आज़माता है। पता समान है, इसलिए केवल पते पर आधारित कोई नियम उन्हें अलग नहीं कर सकता, और जो भी प्रतिक्रिया शुरू होती है, वह दोनों पर लागू होती है।
यह पतों को नज़रअंदाज़ करने का तर्क नहीं है। यह याद रखने का तर्क है कि संकेत क्या मापता है, क्योंकि VPN लॉगिन के आसपास अधिकतर चौंकाने वाला व्यवहार गलत स्तर पर नियंत्रण लगाने से आता है, गलत अवलोकन से नहीं।
एग्ज़िट को ब्लॉक करना अजनबियों को क्यों सज़ा देता है
पता-स्तरीय ब्लॉक लागू करना सस्ता और निशाना बनाना महंगा है। इसका प्रभाव-दायरा उस पते के पीछे का हर सत्र है, और इसीलिए साझा पतों और NAT के व्यवहार का परिचालन दस्तावेज़ीकरण में अपना इतिहास है: वही तर्क IETF के साझा स्रोत पतों और पता-आधारित फ़िल्टरिंग के दुष्प्रभावों पर काम में दिखता है।
| Signal | What it provides evidence about | What it cannot settle |
|---|---|---|
| Source address and its reputation | The network path, and how that path behaved recently for others | Which account or person is behind the request |
| Authenticator result | Whether the account claim was proved at the required strength | Whether the account's owner initiated it |
| Request timing and volume | Whether the pattern looks automated or burst-like | Whether the intent was malicious or a shared client |
| Application event history | What this account has done while signed in | Anything about requests that never authenticated |
ब्लॉक जो दो विफलताएँ पैदा करता है, उन पर विचार कीजिए। उसी एग्ज़िट के पीछे का वैध ग्राहक सेवा से वंचित होता है और सहायता टिकट खोलता है जो दुरुपयोग से अधिक महंगा पड़ता है। वास्तविक हमलावर हज़ारों के पूल में अगले एग्ज़िट पर चला जाता है और जारी रखता है, बिना दोबारा कनेक्ट होने के अलावा कुछ खर्च किए।
आनुपातिकता वह छूटा हुआ कदम है। बार-बार असफल साइन-इन, स्वचालित अनुरोधों का झोंका और प्रमाणित अनुमति उल्लंघन तीन अलग घटनाएँ हैं, और केवल दूसरी ही पता-आकार की समस्या लगती है। उसी साइट-व्यापी नेटवर्क प्रतिबंध को तीनों पर लागू करना यही है कि कैसे एक सुरक्षा नियंत्रण सहायता कतार बन जाता है।
निर्णय वहाँ रखिए जहाँ सबूत हैं
खाता-स्तरीय नियंत्रण खाते का पतों के आर-पार अनुसरण करते हैं, जो उस इकाई से मेल खाता है जो वास्तव में आपके लिए मायने रखती है। दर-सीमा, बार-बार विफलता के बाद प्रतीक्षा अवधि और संवेदनशील कार्यों के लिए चरणबद्ध प्रमाणीकरण सब खाते या कार्य पर काम करते हैं, नेटवर्क पथ पर नहीं। यह उस इकाई से बेहतर मेल खाता है जिसकी आप वास्तव में रक्षा करते हैं। यह हमलावर से नया एग्ज़िट पता खोजने की प्रेरणा भी हटा देता है।
NIST की प्रमाणीकरण मार्गदर्शिका इन्हें जोखिम आकलन के इनपुट मानती है और संकेतों में पता, भू-स्थिति और अनुरोध का समय गिनाती है, जो ठीक वही ढाँचा है जो उधार लेना चाहिए: संकेत निर्णय को सूचित करता है, वह प्रमाणकर्ता की जगह नहीं लेता। उस सूची को इनपुट के रूप में पढ़िए, प्रतिबंधित करने योग्य चीज़ों की मेन्यू के रूप में नहीं। प्रमाणकर्ता अब भी प्रमाण देता है, और अन्य संकेत केवल तय करते हैं कि उसके चारों ओर कितना घर्षण रखना है।
दो डिज़ाइन बाधाएँ खाता-स्तरीय दृष्टिकोण को अपनी ही बाधा बनने से रोकती हैं। दर-सीमा को सुरक्षित समीक्षा पथ चाहिए ताकि उपयोगकर्ता क्रेडेंशियल प्रकाशित किए बिना गलत वर्गीकरण की रिपोर्ट कर सके, और चरणबद्ध चुनौतियों का उत्तर पासवर्ड या असत्यापित सहायता संपर्क को दिए गए एकबारगी कोड से नहीं दिया जाना चाहिए।
बाहर से एक निष्पक्ष नीति कैसी दिखती है
लिखिए कि हर नियंत्रण किस निर्णय का समर्थन करता है, फिर जाँचिए कि नियंत्रण की सूक्ष्मता मेल खाती है। पता नियंत्रण नेटवर्क से आने वाले ट्रैफ़िक के बारे में सवालों के जवाब देते हैं; खाता नियंत्रण खाते के बारे में सवालों के जवाब देते हैं; एप्लिकेशन घटनाएँ प्रमाणीकरण के बाद के व्यवहार के बारे में सवालों के जवाब देती हैं। जो नीति तीनों का नाम लेती है वह लेखापरीक्षा योग्य है, और जो केवल VPN ट्रैफ़िक कहती है वह नहीं।
फिर नियमों की संख्या नहीं, परिणाम मापिए। अनधिकृत प्रयास घटने चाहिए, वैध उपयोगकर्ताओं के पास समर्थित रास्ता बना रहना चाहिए, और प्रति हज़ार लॉगिन सहायता संपर्कों की संख्या नहीं बढ़नी चाहिए। जो ब्लॉक पहला आँकड़ा सुधारता है और बाकी दो बिगाड़ता है, उसने समस्या को खिसकाया है, हल नहीं किया।
VPN कनेक्शन स्वीकार करना और दुरुपयोग नियंत्रण लागू करना अनुकूल लक्ष्य हैं। जो संस्करण काम करता है वह स्रोत पते को कई इनपुट में से एक मानता है, सबूत के अनुरूप सबसे संकीर्ण नियंत्रण लागू करता है, और गलत वर्गीकृत व्यक्ति के लिए ईमानदार रास्ता छोड़ता है। जो संस्करण विफल होता है वह पते को संदिग्ध मानता है और उसे नीति कहता है।