Linux वर AnyConnect: लॉगिन क्रम सुरक्षितपणे स्क्रिप्ट करणे

Cisco AnyConnect सोबत येणारा vpn क्लायंट संभाषणासारखा वागतो: तो प्रॉम्प्ट छापतो, एका ओळीची वाट पाहतो आणि नंतर पुढचा छापतो. ते संभाषण फाइल किंवा पाईपमधून दिल्यास तोच बायनरी देखरेखीशिवाय चालतो. तंत्र एक रीडायरेक्ट आणि क्रमाने मांडलेली उत्तरांची यादी आहे, आणि स्क्रिप्ट विश्वासार्ह आहे का हे रीडायरेक्ट नाही तर तीच यादी ठरवते.

प्रत्यक्षात दोन गोष्टी हे तोडतात. गेटवे काही अधिक विचारले की प्रॉम्प्टचा क्रम बदलतो, आणि साठवलेला पासवर्ड एक टायपिंग चूक खाते लॉकआउटमध्ये बदलतो. क्रमाला आवृत्तीबद्ध डेटा म्हणून पहा जो कोणत्याही गेटवे बदलानंतर तुम्ही तुलना करू शकता. पुन्हा प्रयत्न करण्याऐवजी मोठ्याने अपयशी व्हा, कारण लूप हाच चुकीचा टाइप केलेला पासवर्ड लॉक झालेले खाते होण्याचा मार्ग आहे.

एक क्रम, क्लायंट ज्या क्रमाने विचारतो त्याच क्रमाने

क्लायंट एकदा इंटरॅक्टिव्ह पद्धतीने चालवा आणि प्रत्येक प्रॉम्प्ट ज्या क्रमाने दिसतो त्याच क्रमाने लिहून ठेवा. ते ट्रान्स्क्रिप्ट उत्तर-फाइल होते. फाइल बायनरीमध्ये रीडायरेक्ट करताना पहिली ओळ कनेक्शन कमांडच असली पाहिजे, म्हणूनच क्रम वापरकर्तानावाने नाही तर होस्टनावाने सुरू होतो.

connect vpn.example.com
0
<username>
<password>
y
exit

रिकामा 0 गेटवे यादी देतो तेव्हा पहिला कनेक्शन प्रोफाइल निवडतो; तुमचा गेटवे जो इंडेक्स छापतो तो वापरा. y लॉगिन बॅनर स्वीकारतो, म्हणून बॅनर नसल्यास ती ओळ काढा आणि तुमचा गेटवे अतिरिक्त प्रश्न विचारतो तिथे एक ओळ घाला. शेवटचा exit शेवटचे उत्तर संपल्यावर क्लायंटला स्वच्छपणे संपण्यास परवानगी देतो.

/opt/cisco/anyconnect/bin/vpn -s < anyconnect.txt

येथे नॉन-इंटरॅक्टिव्ह मोड ऐच्छिक नाही. -s शिवाय क्लायंट टर्मिनल ताब्यात घेऊ शकतो आणि रीडायरेक्ट केलेले इनपुट दुर्लक्षित करू शकतो; त्यासह उत्तरे स्ट्रीममधून वाचली जातात आणि प्रक्रिया परत येते. बायनरीला उच्च विशेषाधिकार आवश्यक असतील तिथे कॉल sudo -n मध्ये गुंडाळा, जेणेकरून स्क्रिप्ट पासवर्ड प्रॉम्प्टवर अडकण्याऐवजी लगेच अपयशी होईल.

उत्तर-फाइल कुठे गळते

पासवर्ड असलेली फाइल एक क्रेडेन्शियल आहे, म्हणून तिला त्याची परवानगी द्या: मोड 600, काम चालवणाऱ्या खात्याच्या मालकीत, आणि कधीही सामायिक किंवा सिंक केलेल्या डिरेक्टरीत नाही. नंतर दुरुस्त करण्याऐवजी मोड आधीच लागू करून तयार करा, कारण लिहिणे आणि chmod दरम्यान फाइल क्षणभर सर्वांना वाचनीय असते.

install -m 600 /dev/null ~/.config/anyconnect.txt
chmod 700 ~/.config

दुसरा अर्धा भाग argv आहे. आर्ग्युमेंट म्हणून दिलेला पासवर्ड प्रक्रिया सूचीबद्ध करणाऱ्या प्रत्येक स्थानिक वापरकर्त्याला दिसतो, आणि तो शेल इतिहासातही जातो. त्याऐवजी तो फाइल डिस्क्रिप्टर किंवा पर्यावरण चलातून वाचा, आणि पेलोड अवतरणात ठेवा जेणेकरून शेलला आत काहीही विस्तारता येणार नाही.

printf '%s\n' 'connect vpn.example.com' '0' "$VPN_USER" "$VPN_PASS" 'y' 'exit' \
  | sudo -n /opt/cisco/anyconnect/bin/vpn -s

अवतरणांकडे लक्ष द्या. दुहेरी अवतरणात ! असलेला पासवर्ड क्लायंटला दिसण्यापूर्वीच इंटरॅक्टिव्ह शेल विस्तारू शकतो, आणि अपयश प्रोटोकॉल समस्येसारखे दिसणारे सामान्य event-not-found त्रुटी म्हणून येते.

बोगदा सिद्ध करा, नंतर बंद करा

जोडलेली स्थिती फक्त क्लायंटला सत्र आहे असे वाटते एवढेच सिद्ध करते. केवळ कॉर्पोरेट नेटवर्कच्या आतून उत्तर देणारा होस्ट निवडा आणि दुसरे काही करण्यापूर्वी एकदा तपासा. तिथले अपयश मार्गनिर्देशन किंवा धोरणातील दोष आहे, आणि लॉगिन पुन्हा चालवल्याने ते बदलणार नाही.

/opt/cisco/anyconnect/bin/vpn state
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 10 https://<internal-host>/
/opt/cisco/anyconnect/bin/vpn disconnect

डिस्कनेक्टपूर्वी आणि नंतर स्टेट आउटपुट तपासा. जुन्या सत्रासह सोडलेला क्लायंट पुढील कनेक्शन नाकारू शकतो, तर स्क्रिप्ट अजूनही यशाचा अहवाल देते, आणि केवळ एक्झिट कोड पाहिल्यास हा अपयशप्रकार अदृश्य असतो. दुसऱ्या वाचनावर एकट्याने विश्वास ठेवण्याऐवजी दोन्ही वाचने तुलना करा. शेल प्रोफाइलमधील टोपणनावे दैनंदिन वापरासाठी पुरेशी आहेत, पण नियोजित केलेले काहीही इतर कोणत्याही देखरेखमुक्त कामाप्रमाणे तीच क्रेडेन्शियल आणि ओळख पुनरावलोकनास पात्र आहे.

स्थिर यादी सुरक्षित राहणे थांबते तेव्हा

उत्तर-फाइल आजचा प्रॉम्प्ट क्रम एन्कोड करते. बदललेला बॅनर, सक्तीचा पासवर्ड बदल किंवा दुसऱ्या घटकाचे आव्हान त्याला खाते लॉक करू शकणाऱ्या लूपमध्ये बदलते, म्हणून स्क्रिप्टने पुन्हा सुरू करण्याऐवजी पहिल्या अनपेक्षित उत्तरावर बाहेर पडले पाहिजे.

क्लायंटने छापलेले पकडा, शून्येतर स्थिती परत करा आणि निर्णय कॉलरवर सोडा. गेटवे दुसरा घटक मागतो तिथे, प्रामाणिक उत्तर असे आहे की त्या प्रोफाइलसाठी देखरेखमुक्त लॉगिन उपलब्ध नाही, क्रमाला अजून एक ओळ हवी आहे असे नाही.

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

AnyConnect नसलेली प्रोफाइल

Cisco च्या दोन जुन्या क्रेडेन्शियल शैली यासोबत गोंधळल्या जातात. vpnc प्रोफाइल IPSec ID मागते, जे प्रत्यक्षात गटाचे नाव आहे, नंतर गट गुप्त, नंतर तुमची स्वतःची क्रेडेन्शियल, आणि तीनही गेटवे चालवणाऱ्याकडून येतात. जुने Cisco IPsec AnyConnect पेक्षा वेगळे प्रोटोकॉल आहे, म्हणून vpnc फक्त-AnyConnect सेवेपर्यंत पोहोचू शकत नाही; openconnect --protocol=anyconnect त्या कामासाठीचा मुक्त क्लायंट आहे.

.pcf फाइल जुन्या क्लायंट प्रोफाइलचे वर्णन करते. त्यातील होस्ट, गटाचे नाव आणि गट पासवर्ड Cisco IPsec बोलणाऱ्या क्लायंटमध्ये हाताने पुन्हा भरता येतात, तरी फाइल सार्वत्रिक आयात नाही आणि कोणताही गैर-डीफॉल्ट पोर्ट किंवा बोगदा मोड सहसा हस्तांतरणात नाहीसा होतो.

गेटवे प्रत्यक्षात काय देतो यापासून सुरुवात करा, नंतर ते प्रोटोकॉल बोलणारा क्लायंट निवडा. दुसऱ्या साइटवरून प्रोफाइल कॉपी करणे हाच मार्ग आहे ज्याने लोक कधीही समस्या नसलेल्या क्रेडेन्शियल डीबग करू लागतात.