OpenVPN में RADIUS जोड़ना: प्लगइन या स्क्रिप्ट हुक?

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

मिथक: प्लगइन ही समर्थित रास्ता है

प्लगइन एक साझा ऑब्जेक्ट है जो OpenVPN प्रक्रिया में लोड होता है, इसलिए उसे उस इंटरफ़ेस से मेल खाना चाहिए जो वह प्रक्रिया देती है। बिल्ड बदलते हैं, पैकेजिंग बदलती है, और पुराने इंटरफ़ेस के लिए कंपाइल की गई लाइब्रेरी लोड होने से सीधे इनकार कर देती है। सर्वर कॉन्फ़िगरेशन में कुछ भी उस अंतर को नहीं पाट सकता, इसलिए "बस radiusplugin इंस्टॉल करें" सलाह ऐसे सर्वर पर खत्म होती है जो शुरू नहीं होता।

स्क्रिप्ट हुक इसके बजाय प्रक्रिया के बाहर रहता है। OpenVPN एक प्रोग्राम चलाता है, उसे क्रेडेंशियल देता है और फैसला पढ़ता है। यही अलगाव उसे अपग्रेड में टिकाए रखता है, और यही उसे आपकी ज़िम्मेदारी भी बनाता है ऐसे तरीके से जो प्लगइन कभी नहीं था।

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

प्लगइन ने क्या एक साथ बांधा था

प्लगइन के पास RADIUS होस्ट, साझा गुप्त, पुनःप्रयास संख्या और समय सीमा वाली अपनी कॉन्फ़िगरेशन फ़ाइल थी, और सर्वर कॉन्फ़िगरेशन उसका एक पंक्ति में संदर्भ देता था। क्रेडेंशियल हैंडलिंग सर्वर प्रक्रिया के अंदर ही रहती थी, यानी पासवर्ड कभी उस प्रक्रिया सीमा को पार नहीं करता था जिसे व्यवस्थापक को सुरक्षित करना होता था।

कीमत जुड़ाव थी। हर OpenVPN अपग्रेड असंगत इंटरफ़ेस का जोखिम लेता था, और पैकेज को फिर से बनाने वाला हर वितरण ऐसी लाइब्रेरी बनाने का जोखिम लेता था जो अब मेल नहीं खाती। जब ऐसा होता है, विफलता ज़ोरदार और तत्काल होती है, और यही डिज़ाइन की एकमात्र दया है।

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

स्क्रिप्ट हुक वास्तव में किस पर भरोसा करता है

हुक auth-user-pass-verify और डिलीवरी तंत्र के साथ कॉन्फ़िगर होता है: पर्यावरण चर या अस्थायी फ़ाइल। पर्यावरण रूप में OpenVPN को script-security 3 चाहिए, वह प्रलेखित स्तर जो स्क्रिप्ट को पासवर्ड खोलने की अनुमति देता है। वह स्तर डिफ़ॉल्ट को जानबूझकर कमज़ोर करना है, और उसे औचित्य संलग्न अनुमति मानना चाहिए।

स्क्रिप्ट जिसे भी छूती है, वह उस भरोसे को विरासत में पाता है। उसका स्वामी root होना चाहिए, समूह या अन्य के लिए लिखने योग्य नहीं, पूर्ण पथ से संदर्भित, और ऐसी किसी जगह से मुक्त होना चाहिए जहां अविश्वनीय मान शेल तक पहुंचे। हर चर को उद्धरण में रखें, अप्रत्याशित अक्षर अस्वीकार करें, और दिए गए उपयोगकर्ता नाम से कभी कमांड न बनाएं। हर लॉगिन प्रयास पर root के रूप में चलने वाली स्क्रिप्ट ठीक उन चार गुणों के कारण एक बार समीक्षा के योग्य है।

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

फ़ाइल-डिलीवरी रूप पर्यावरण विरासत की समस्या से बचता है और सीमित अनुमतियों वाली अस्थायी फ़ाइल के जरिए स्क्रिप्ट को क्रेडेंशियल देता है। अगर आपका क्लाइंट इसे समर्थन देता है, तो यह आमतौर पर बेहतर डिफ़ॉल्ट है, हालांकि विफलता पर साफ करने के लिए एक और ऑब्जेक्ट जोड़ता है।

एग्ज़िट कोड तय करते हैं कि आप खुले में विफल होंगे या नहीं

स्क्रिप्ट की एग्ज़िट स्थिति ही फैसला है: शून्य स्वीकार करता है, गैर-शून्य अस्वीकार करता है। परेशानी पैदा करने वाला पैटर्न वह शेल स्क्रिप्ट है जो तभी स्वीकार करती है जब RADIUS प्रतिक्रिया में कोई विशिष्ट स्वीकृति टोकन हो और बाकी सब के लिए विफलता लौटाती है, क्योंकि वह तीन अलग घटनाओं को एक उत्तर में मिला देती है। गलत पासवर्ड, अगम्य सर्वर और विकृत प्रतिक्रिया सब एक ही अस्वीकृति बन जाते हैं।

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

दो आदतें बाकी को समझदार रखती हैं। अगर RADIUS प्राधिकरण है, तो पासवर्ड जांचने की एकमात्र जगह वही होनी चाहिए, क्योंकि छाया तालिका एक ही सवाल के दो जवाब बनाती है और दूसरा ऐसी हमला सतह है जिसे कोई नहीं देखता। और याद रखें कि हुक हर पुनःप्रयास पर फिर बुलाया जाता है, इसलिए धीमी स्क्रिप्ट के साथ अधीर क्लाइंट पासवर्ड अनुमान के लिए एम्प्लीफायर बन जाता है, जब तक आप RADIUS पक्ष पर देरी या नीति न जोड़ें।

प्रमाणपत्र जाने पर आप क्या छोड़ते हैं

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

कंट्रोल-चैनल सुरक्षा बनाए रखें ताकि अपुष्ट सहकर्मी हैंडशेक को जांच या बाढ़ न सके, और username-as-common-name का उपयोग करें जब प्रति-उपयोगकर्ता कॉन्फ़िगरेशन सामान्य नाम पर निर्भर हो। प्रबंधित गेटवे अक्सर इसे अलग तरह से हल करते हैं, प्रमाणपत्र प्रमाणीकरण को ऐसे गेटवे पर समाप्त करते हैं जो RADIUS से EAP-TLS बोलता है, और उस स्थिति में इनमें से कोई भी सर्वर निर्देश लागू नहीं होता। वह मॉडल कॉपी करें जिसे आपका अपना प्लेटफ़ॉर्म प्रलेखित करता है, पड़ोसी उत्पाद का नहीं। मायने रखने वाले निर्देश इतने अलग हैं कि उन्हें मिलाने से ऐसा कॉन्फ़िगरेशन बनता है जो पार्स होता है और फिर किसी को प्रमाणित नहीं करता।