साझा 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 जडान स्वीकार गर्नु र दुरुपयोग नियन्त्रण लागू गर्नु अनुकूल लक्ष्य हुन्। काम गर्ने संस्करणले स्रोत ठेगानालाई धेरै इनपुटमध्ये एक मान्छ, प्रमाणसँग मिल्ने सबैभन्दा साँघुरो नियन्त्रण लागू गर्छ, र गलत वर्गीकरण भएको व्यक्तिका लागि इमानदार मार्ग छोड्छ। असफल हुने संस्करणले ठेगानालाई शंकास्पद मान्छ र त्यसलाई नीति भन्छ।