दुई लगइन जाँच दुई कारक होइनन्: VPN र RADIUS

VPN गेटवेमा दोस्रो प्रमाणीकरण ब्याकएन्ड थप्नु दोस्रो कारक थप्नु जस्तो लाग्छ। सामान्यतया यसले दोस्रो जाँच थप्छ, जुन फरक असफलता विधि भएको फरक वस्तु हो। दुवै सफल हुनुपर्छ कि, प्रत्येकले के प्रमाणित गर्छ र एउटा उपलब्ध नभएमा के हुन्छ भन्ने तीन फरक निर्णय हुन्। गल्ती गरे गेटवे प्रदर्शनमा बढी कडा र अवरोधको समयमा बढी कमजोर हुन्छ।

दोस्रो ब्याकएन्डले वास्तवमा के प्रमाणित गर्छ

स्थानीय खाता खोजीले नाम डेटाबेसमा छ र पासवर्ड त्यससँग मिल्यो भन्ने प्रमाणित गर्छ। RADIUS आदानप्रदानले RADIUS सर्भरले प्राप्त विशेषताहरूका लागि Access-Accept फर्कायो भन्ने प्रमाणित गर्छ। दुवैमध्ये कुनै पनि कथनले कारक प्रकार उल्लेख गर्दैन, किनकि दुवैले ज्ञान जाँच्छन्। र NIST को डिजिटल पहिचान निर्देशिका ले फरक कारक प्रकार र तिनका प्रमाणकहरू गन्छ, सर्भर वा सङ्केतहरू होइन।

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

RADIUS ले एउटा प्रमाणित गर्ने कुराको अगाडि हुँदा वास्तविक दोस्रो कारक बोक्न सक्छ, जस्तै पुश स्वीकृति वा हार्डवेयर टोकन। खामले प्रयोगकर्ताले कुन प्रमाणकहरू देखाए भनी बताउँदैन, त्यसैले गेटवेको लेबल होइन, ब्याकएन्ड नीति पढ्नुहोस्।

AND, OR र फलब्याक फरक उत्पादन हुन्

कार्यान्वयन तुलना गर्नुअघि तपाईंको आवश्यकतामा दुवैको अर्थ के हो निर्धारण गर्नुहोस्। AND नीतिले हरेक नामित जाँच पास हुनुपर्छ भन्ने माग गर्छ, OR नीतिले सफल हुने स्वीकार गर्छ, र फलब्याकले दोस्रोलाई घोषित असफलता अवस्थामा मात्र प्रयास गर्छ। यी तीन अवरोधको समयमा विपरीत व्यवहार गर्छन्, र सामान्यतया तीमध्ये एउटा मात्र समीक्षाको अभिप्राय हुन्छ।

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

फलब्याक सबैभन्दा धेरै शंकाको योग्य छ, किनकि केही बिग्रिएपछि काम जारी राख्न यसको अस्तित्व छ। RADIUS उपलब्ध नभएको बेला स्थानीय पासवर्ड स्वीकार गर्ने फलब्याकले केन्द्रीय नीतिलाई दोस्रो, कमजोर ढोकामा परिणत गरेको छ।

OpenVPN को दोहोरो जाँच एउटा ठोस उदाहरण हो

समुदाय OpenVPN 2.6 ले दुवै सक्षम हुँदा क्लाइन्ट प्रमाणपत्र र कन्फिगर गरिएको auth-user-pass-verify स्क्रिप्ट दुवै आवश्यक ठान्छ। त्यो प्रमाणपत्र जाँच र प्रमाणहरूको स्क्रिप्टबीचको अभिलेखित AND हो, र यो साँच्चै दुई जाँच हुन्। तैपनि यो स्वतः दुई कारक प्रकार होइन, किनकि स्क्रिप्टले पासवर्ड मात्र प्रमाणित गर्न सक्छ।

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

प्रमाणपत्र-मात्र मोड एक जाँच हो, जुन PIN ले सुरक्षित हुन सक्ने वा नहुन सक्ने कुञ्जीमा टिकेको छ। PIN ले त्यही प्रमाणलाई ज्ञान र स्वामित्वमा त्यतिबेला मात्र बदल्छ जब कुञ्जी त्यसबिना प्रयोग गर्न सकिँदैन। त्यो कुञ्जीलाई डिस्कमा इन्क्रिप्ट नगरी छोड्दा दोस्रो भाग फाइल अनुमतिमा घट्छ।

यन्त्र उत्पादकहरूले आफ्नै प्लम्बिङ बनाउँछन्, प्रायः वेब कन्सोलपछाडि PAM मोड्युल वा RADIUS प्लगइन। समुदायको व्यवहार दोहोरो जाँच कस्ता देखिन्छन् भन्ने सन्दर्भ हो, यन्त्रले तिनलाई कसरी जोड्छ भन्ने विवरण होइन।

तपाईंको गेटवेमा संयोजन जाँच्नुहोस्

कन्सोल सारांशमा भरोसा गर्नुअघि कन्फिगरेसन पढ्नुहोस्। नीति निर्धारण गर्ने लाइनहरू प्रमाणपत्र मोड, प्रमाण स्क्रिप्ट र प्लगइन क्रम हुन्।

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep ले प्रमाणपत्र आवश्यक छ कि र त्यसपछि कुन स्क्रिप्ट चल्छ देखाउँछ, र क्रम नामले संकेत गरेभन्दा बढी महत्त्वपूर्ण छ। प्रमाणपत्र डम्पले गेटवेले देख्ने पहिचान दिन्छ, जोडाइ नक्साका लागि आवश्यक CN र क्रमिक नम्बरसहित। RADIUS परीक्षण नकारात्मक अवस्था हो: गलत पासवर्डले Access-Reject र सहीले Access-Accept दिनुपर्छ। अस्वीकृत प्रमाणले अझै सत्र दिन्छ भने, स्क्रिप्ट प्रमाणीकरण मार्गमै छैन।

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

आवश्यकतालाई नकारात्मक अवस्थाका रूपमा लेख्नुहोस्

उपयोगी आवश्यकताले प्रमाणहरू, ती प्रस्तुत गर्न अनुमतिप्राप्त खाताहरू र जाँचकर्ता नभएको बेलाको नतिजा नाम दिन्छ। यसले यन्त्र पहिचान र व्यक्ति पहिचानबीचको अनुमत जोडी पनि बताउँछ। त्यो खरिद आदेशका उत्पादन नामभन्दा बढी सटीक छ, र परीक्षण गर्न सकिन्छ।

स्वीकृतिमा चार अस्वीकृति समावेश हुनुपर्छ: अयोग्य स्थानीय खाता, हराएको आवश्यक प्रमाण, अवैध दोस्रो कारक र अगम्य आवश्यक ब्याकएन्ड। प्रत्येक अस्वीकृतिका लागि अरूबाट छुट्याउने लग लाइन चाहिन्छ, नत्र अर्को घटना अनुमानबाट सुरु हुन्छ। कुन घटकले कुन निर्णय लियो अभिलेख गर्नुहोस्, किनकि गेटवे, RADIUS सर्भर र डाइरेक्टरीले एकअर्कालाई दोष दिन्छन्।

कुनै पनि प्लगइन वा फर्मवेयर परिवर्तनपछि चार अस्वीकृति फेरि चलाउनुहोस्। ती सस्ता छन्, र तिनले जोगाउने नीति नै आक्रमणकारीले पहिले जाँच्ने भाग हो।