OpenConnect लॉगिन कुकीला टनेलमध्ये कसे बदलते?

OpenConnect दोन वेगळ्या देवाणघेवाणी एका अल्पायुषी मूल्याने जोडते: वेब लॉगिन आणि VPN टनेल। पहिली देवाणघेवाण सामान्य HTTPS आहे: ओळखपत्रे, एक SAML फेरी किंवा टोकन गेटवेकडे जाते, आणि प्रतिसाद प्रमाणीकरण कुकी घेऊन येतो। दुसरी देवाणघेवाण तीच कुकी त्याच गेटवेसमोर वेब टप्पा आधीच झाला याचा पुरावा म्हणून सादर करते, आणि तेव्हाच टनेल वर येते।

लॉगिनच्या वेळी टनेलबद्दल काहीही ठरवले जात नाही। हाच समजून घेण्यासारखा भाग आहे, कारण बहुतेक स्क्रिप्ट चुका कुकी ही साठवायचा पासवर्ड किंवा रहदारीचे रक्षण करणारी किल्ली आहे असे गृहीत धरतात, पण प्रत्यक्षात ती विशिष्ट गेटवे सत्रासाठीचे वाहक तिकीट असते।

क्लायंट आणि गेटवे क्रमाने काय देवाणघेवाण करतात

प्रमाणीकरणाचा टप्पा सामान्य संरक्षित वेबसाइटसारखा दिसतो। OpenConnect वापरकर्त्याची ओळखपत्रे पाठवते, किंवा गेटवेच्या पुनर्निर्देशनाचे अनुसरण करून ओळख प्रदात्याकडे जाते, आणि गेटवे प्रमाणीकरण कुकी असलेल्या दस्तऐवजासह उत्तर देते। AnyConnect प्रोटोकॉलमध्ये ते मूल्य पुढील विनंत्यांमध्ये कुकी हेडरमध्ये जाते, सहसा webvpn सारख्या नावाने, आणि पुस्तिका त्याला सत्र पुढे नेणारे ओळखपत्र मानते।

दुसरा टप्पा म्हणजे ती कुकी जोडलेली गेटवेच्या VPN अंतबिंदूकडे जाणारी CONNECT विनंती। गेटवे ती तपासते, पत्ता नेमून देते, आणि क्लायंट TLS वर CSTP सुरू करतो, सत्र असेल तर DTLS हा ऐच्छिक जलद माहिती मार्ग असतो। याच क्षणी टनेलचे मापदंड, मार्ग, DNS संयोजन आणि सत्राच्या रहदारीच्या किल्ल्या ठरतात। कुकीने क्लायंटला दारातून पुढे केले; तिने काहीही कूटबद्ध केले नाही।

हा क्रम openconnect --authenticate का आहे हे स्पष्ट करतो। ते चालवा, ते वेब टप्पा करते, COOKIE, HOST, CONNECT_URL आणि FINGERPRINT अशा शेल चलांचा छोटा खंड छापते, आणि मग कोणतेही टनेल तयार होण्यापूर्वी बाहेर पडते। त्यानंतर रॅपर स्क्रिप्ट त्या मूल्यांसह खरे कनेक्शन सुरू करू शकते, आणि हेडलेस किंवा दोन कंटेनर तैनातीसाठी नेमके हेच विभाजन लागते।

कुकी सत्राची वाहक आहे, किल्ली नाही

त्या मूल्याशी वेब अनुप्रयोगातील सत्र ओळखीशी जसे वागता तसे वागा। तिच्या आयुष्यात ती ज्याच्याकडे असेल तो गेटवेकडे त्या सत्रास पात्र असलेल्या टनेलची मागणी करू शकतो, म्हणून तिची गुप्तता महत्त्वाची आहे। पण प्रत तयार केल्याने रहदारी उघड होत नाही, कारण टनेलची गोपनीयता TLS हस्तांदोलन आणि त्यातून निघालेल्या किल्ल्यांमधून येते, कुकीच्या मालिकेतून नाही।

हे कायमचे परवानगीही नाही। सत्र किती काळ जगते हे गेटवे आणि ओळख प्रदाता ठरवतात, आणि अजूनही लॉगिन झालेले पृष्ठ दाखवणारा ब्राउझर टनेल सत्र अजून वैध आहे का याबद्दल काहीही सांगत नाही। मुदत संपल्यावर पुन्हा जोडणे म्हणजे वेब टप्पा पुन्हा करून नवीन कुकी तयार करणे, आणि पुनर्प्रमाणीकरणाचा हेतू हाच आहे, अभियांत्रिकीने टाळावा असा उपद्रव नाही।

कुकीला इतर ओळखपत्रांचा सार्वत्रिक पर्याय मानू नका। SAML दावा, ब्राउझर पासवर्ड आणि दुसऱ्या सेवेने दिलेली कुकी वेगवेगळ्या प्रेक्षकांच्या वेगवेगळ्या वस्तू आहेत, आणि एक दुसऱ्याच्या क्षेत्रात चिकटवल्यास सहसा गेटवेवर अपयश येते किंवा अधिक वाईट म्हणजे चुकीच्या विश्वास सीमेविरुद्ध यश मिळते।

प्रती न ठेवता कुकी पुढे पाठवणे

Linux वर सर्वात सुरक्षित यांत्रिक हस्तांतरण म्हणजे प्रमाणित इनपुट। --cookie-on-stdin मूल्य stdin मधून वाचते, त्यामुळे कुकी प्रक्रियेच्या आर्ग्युमेंट यादीत कधीही दिसत नाही, जिथे कोणताही स्थानिक वापरकर्ता ती ps ने वाचू शकतो। एका प्रक्रियेत प्रमाणीकरण करून दुसऱ्यात टनेलला खाद्य देणारी पाइपलाइन मूल्य फाइल किंवा पर्यावरण चलात नाही तर पाइपमध्ये ठेवते।

आर्ग्युमेंट आणि पर्यावरण चल वेगवेगळ्या कारणांमुळे कमकुवत आहेत। आर्ग्युमेंट क्लायंटच्या संपूर्ण आयुष्यात प्रक्रिया तक्त्यात दिसते आणि बऱ्याचदा शेल इतिहासात जाते। पर्यावरण चल अपत्य प्रक्रियांना वारशाने मिळते, आणि युनिट फाइलमध्ये ते ठरवणारे systemd युनिट रहस्य वाचनीय संरचनेत ठेवते। फाइलच आवश्यक असल्यास ती सेवा खात्यापुरती मर्यादित ठेवा आणि सत्र संपल्यावर ती काढून टाका।

विशेषाधिकाराची सीमाही जाणूनबुजून ठेवा। ओळख प्रदात्याशी बोलणारी आणि कदाचित ब्राउझर उघडणारी प्रक्रिया त्या लॉगिनच्या मालक वापरकर्त्याप्रमाणे चालली पाहिजे। मार्ग, DNS आणि टनेल उपकरण संयोजित करणाऱ्या प्रक्रियेस अधिक विशेषाधिकार लागू शकतात। root च्या मालकीच्या टनेलला कुकी उपलब्ध व्हावी म्हणून संपूर्ण ब्राउझर root म्हणून चालवणे ही चुकीची अदलाबदल आहे, आणि आधुनिक OpenConnect संयोजन ते मूल्य त्या सीमेपार स्पष्टपणे देऊ शकतात।

लॉगिंगही त्याच संशयास पात्र आहे। तपशीलवार क्लायंट आउटपुट, सहाय्यक स्क्रिप्ट आणि गेटवे निदान हे सर्व विनंतीची सामग्री पुनरावृत्त करू शकतात, आणि प्रत्येक लॉग पातळी कुकी लपवत नाही। तुम्हाला लागणारी सर्वात लहान त्रुटी नोंद घ्या, ती सामायिक मार्गांबाहेर ठेवा, आणि तिकिटाला जोडण्यापूर्वी लपवलेला नमुना तपासा।

दुसऱ्या टप्प्यातील पडताळणी आणि मुदत संपणे

दुसऱ्या टप्प्यानेही सर्व्हरची पडताळणी करायची आहे। --authenticate छापते ते FINGERPRINT pin-sha256: स्वरूपातील प्रमाणपत्र पिन आहे, आणि ते --servercert सह टनेल कॉलला दिल्यास पडताळणी तुम्ही प्रमाणीकरण केलेल्या गेटवेवर लंगरित राहते। स्क्रिप्ट सोपी करण्यासाठी प्रमाणपत्र पडताळणी बंद करणे म्हणजे कुकी इच्छित होस्टला दिली जाते याचा एकमेव पुरावा काढून टाकणे।

गेटवे कुकी नाकारतो तेव्हा उपाय नवीन प्रमाणीकरण फेरी आहे, लांब कॅश नाही। कुकी केवळ कनेक्शनच्या आयुष्यापुरती साठवा, बाहेर पडताना तात्पुरत्या फाइल्स काढा, आणि सत्र उघडकीस आल्यास किंवा उपकरण हरवल्यास ओळख प्रदाता किंवा गेटवेची सत्र काढण्याची प्रक्रिया वापरा। कॅश केलेली कुकी MFA मधून सूट नाही।

हे स्वयंचलित करण्यापूर्वी चार गोष्टी तपासा: टनेल योग्य खात्याखाली चालते, कुकी stdin मधून येते, प्रमाणपत्राचा बोटांचा ठसा पिन केलेला आहे, आणि टनेल बंद होताच सत्र टाकून दिले जाते। यापैकी काही नसेल तर स्वयंचलनाने हातचा प्रवाह पुनरुत्पादित करण्याऐवजी कुकीवरील विश्वास वाढवला आहे।