OpenConnect csd-wrapper: लॉगिन से पहले स्क्रिप्ट का ऑडिट करें

प्रोफ़ाइल में --csd-wrapper जोड़ने से कोई स्थानीय स्क्रिप्ट उस डेमन को मिलती है जो उसे लॉगिन के दौरान चलाता है, इसलिए आपके सामने का निर्णय कोड समीक्षा है, कोई वरीयता टॉगल नहीं। यह विकल्प इसलिए है ताकि गेटवे के होस्ट-जाँच घटक को बदला जा सके, और यह आपके द्वारा दिए गए स्क्रिप्ट का पथ लेता है। नीचे सब कुछ यह मानता है कि परिनियोजन का स्वामी पहले ही बता चुका है कि कौन-सी पोस्चर जाँच आवश्यक है; अगर वह हिस्सा अभी खुला है, तो पहले उसे तय करें। रनबुक में चार चरण हैं: विफल चरण का पता लगाएँ, स्क्रिप्ट पढ़ें, वह पहचान चुनें जिसके अंतर्गत वह चलती है, और परिणाम सिद्ध करें।

चरण 1: विफल हुए चरण का पता लगाएँ

क्लाइंट का अंतिम संदेश आमतौर पर कुकी के बारे में होता है, जो श्रृंखला का अंत है, आरंभ नहीं। HTTPS लॉगिन, सर्वर प्रमाणपत्र जाँच, प्रमाणीकरण का आदान-प्रदान और एक पोस्चर घटक—ये सब उस संदेश से पहले बैठते हैं।

उपयोग हो रहा संस्करण और लॉगिन पता दर्ज करें, फिर विस्तृत आउटपुट अपने ही टर्मिनल पर रखते हुए प्रयास दोहराएँ। पहली त्रुटि पढ़ें जो पुनः-प्रयास नहीं है, ट्रांसक्रिप्ट की अंतिम पंक्ति नहीं। अगर लॉग किसी भी आकलन घटक का नाम आने से पहले रुक जाए, तो रैपर अभी आपकी समस्या नहीं है। उस समय इसे जोड़ना केवल उस सतह को चौड़ा करता है जिसे आपको बाद में बचाना होगा।

openconnect --version
openconnect --verbose --user="$VPN_USER" vpn.example.com </dev/null

ट्रांसक्रिप्ट को स्थानीय रखें, क्योंकि कुकीज़ और प्रमाणीकरण प्रतिक्रियाएँ पहुँच सामग्री हैं। चैट थ्रेड में चिपकाया गया ट्रेस क्रेडेंशियल लीक है, भले ही आकलन चरण हानिरहित लगे। त्रुटि का पाठ और प्रवाह में वह बिंदु साझा करें जहाँ वह दिखी, पेलोड कभी नहीं।

चरण 2: स्क्रिप्ट के प्रोफ़ाइल में प्रवेश से पहले उसे पढ़ें

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

sha256sum ./vpn-csd-wrapper.sh
bash -n ./vpn-csd-wrapper.sh

पूरी फ़ाइल चार प्रश्न मन में रखकर पढ़ें: क्या यह बाहर जाने वाली HTTP कॉल करती है, क्या यह क्रेडेंशियल फ़ाइलें या पर्यावरण चर पढ़ती है, क्या यह अस्थायी निर्देशिका से बाहर लिखती है, और क्या कोई शाखा बिना कुछ मापे पास हो रहा पोस्चर बताती है। वह अंतिम पैटर्न एक लॉग पंक्ति के साथ जुड़ा नीति-बायपास है। कॉपी किए गए रैपर इसे विश्वसनीय दिखने वाली जाँच के पीछे छिपा देते हैं। अगर स्क्रिप्ट डिवाइस को देखने से पहले ही तय कर दे कि डिवाइस ठीक है, तो वहीं रुकें।

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

grep -nE 'base64 -d|xxd -r|eval |curl |wget ' ./vpn-csd-wrapper.sh

चरण 3: वह पहचान चुनें जिसके अंतर्गत रैपर चलता है

--csd-user CSD, TNCC या HIP प्रोग्राम चलने के दौरान विशेषाधिकार घटाता है। वह खाता स्थानीय निष्पादन व्यवस्था का हिस्सा है, गेटवे को सौंपा गया उपयोगकर्ता नाम नहीं।

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

sudo -u vpn-csd /usr/local/libexec/vpn-csd-wrapper.sh

विशेषाधिकार घटाना उस नुकसान को सीमित करता है जो खराब स्क्रिप्ट कर सकती है। यह कोड की समीक्षा नहीं करता, रिपोर्ट को सच्चा नहीं बनाता, और यह स्थापित नहीं करता कि गेटवे प्रशासक इस कार्यान्वयन को डिवाइस नीति का पालन मानता है।

चरण 4: बदलाव को उलटने योग्य रखें

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

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

सफल परिनियोजन के बाद एक नहीं, दो चीज़ें जाँचें: सुरंग ऊपर आती है, और जो डिवाइस पोस्चर जाँच में विफल होना चाहिए वह अब भी अस्वीकार होता है। हर किसी के लिए काम करने वाला कनेक्शन इस बात का प्रमाण नहीं है कि आकलन आपके बदलाव से बच गया।

ऐसे शॉर्टकट जो दूसरी समस्या पैदा करते हैं

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

सर्वर सत्यापन बंद करना, पुरानी कुकी दोबारा चलाना और बिना समीक्षा वाली स्क्रिप्टों का ढेर लगाना—ये सब दृश्य विफलता को अदृश्य विफलता से बदलते हैं। अगर स्थापित क्लाइंट समर्थित प्रवाह पूरा नहीं कर सकता, तो अपने मौजूदा प्रवाह को मोड़ने के बजाय स्वीकृत विकल्प माँगें।

OpenConnect मैनुअल --csd-wrapper और --csd-user को अलग-अलग दस्तावेज़ित करता है, और यही वह संकेत है जो मायने रखता है: स्क्रिप्ट और पहचान दो निर्णय हैं। उनकी अलग-अलग समीक्षा करें और दोनों लिख लें। फिर लॉगिन संकेत वह रहस्य नहीं रहता जिसे आप कोड चिपकाकर सुलझाते हैं।