"मनोरंजक XenAPI", या "Citrix XenServer का नया रोमांच"

हाय साथियों!
आज मैं Citrix XenServer 5.6 और इसके साथ काम करने के विभिन्न पहलुओं के बारे में अपनी कहानी जारी रखना चाहूंगा। इस बार मुझे एक सरल (यह प्रतीत होता है!) समस्या को हल करना था: एसएसएच का उपयोग किए बिना डोमे में कमांड निष्पादित करना। कार्यान्वयन के लिए संभावनाओं का अध्ययन करने से इस ओएस के HTTP एपीआई की कुछ मजेदार बारीकियों की खोज हुई: प्राप्त करने के लिए तरीके / आदि / पासवार्ड , rsync का रिमोट निष्पादन , और XenSource पतली सीएलआई प्रोटोकॉल की रूपरेखा। अब मैं आपको बताता हूँ कि एक कहानी का नाम क्या है ...



सबसे पहले, मैं यह बताना चाहूंगा कि एक समान समस्या कैसे उत्पन्न हुई। पिछली श्रृंखला में, मैंने XenServer के लिए सुरक्षा गाइड का एक सार्वजनिक बीटा संस्करण दिखाया, जिसे मैंने एक बुद्धिमान गाइड लिखने की आशा में "देखा" था। एक सिफारिश ( VMWare ESXi के लिए सुरक्षा सख्त गाइड के समान) SSH डेमॉन को अक्षम करना है। प्रेरणा यह है कि एक्सपी के कॉर्पोरेट संस्करण में सक्रिय निर्देशिका के माध्यम से प्रमाणीकरण के साथ एक आरबीएसी प्रणाली का उपयोग करने की क्षमता है। विक्रेता की सिफारिशों के अनुसार, यह मार्ग सुरक्षा के दृष्टिकोण से बेहतर है। मेरे मैनुअल में वर्णित dom0 पर कंसोल स्टार्टअप स्क्रिप्ट के कुछ संशोधन के बाद, एक पासवर्ड के बिना सिस्टम में इसके माध्यम से हो रही है। तदनुसार, डोमे 0 कंसोल पर सीधे जाने के लिए, आपको न केवल पूल-व्यवस्थापक विशेषाधिकारों वाले उपयोगकर्ता के पासवर्ड को जानना होगा, बल्कि खाता जानकारी को भी रूट करना होगा।

ठीक है। अब हम स्वचालित टूल का उपयोग करके ऑपरेटिंग सिस्टम के रिमोट ऑडिट के कार्य के साथ सामना कर रहे हैं। हमारे पास एक्सएमएल-आरपीसी है जो एक्सएनएपीआई के लिए अग्रणी है, इसके लिए प्रलेखन, और उत्कृष्ट ओकेएमएल भाषा में एक्सईएन-ओआरजी स्रोत कोड। हम बाश में आदेशों को निष्पादित करना चाहते हैं और आगे की प्रक्रिया के लिए उनका "निकास" प्राप्त करना चाहते हैं। यह कैसे करना है?

पहले आपको यह समझने की आवश्यकता है कि यह सामान्य तरीके से काम नहीं करेगा (एपीआई के भाग के रूप में प्रदान किए गए कंसोल के माध्यम से)। कंसोल को क्लाइंट की तरफ से कॉल करने की तकनीक को याद करें: आप कंसोल से कनेक्ट करते हैं ( https://<xen_host>/console?ref=OpaqueRef:console_id ), एक वैध https://<xen_host>/console?ref=OpaqueRef:console_id होने, और vtcterm RFB टर्मिनल पर जाएं । यह स्पष्ट है कि यह प्रोटोकॉल आपको रिमोट सर्वर पर माउस क्रिया और बटन प्रेस भेजने की अनुमति देता है, और बदले में स्क्रीन की बिटमैप छवियां प्राप्त करता है। आगे स्पष्ट है: आरएफबी प्रोटोकॉल के आधुनिक संस्करण, अन्य चीजों के बीच, फ़ाइल स्थानांतरण की अनुमति देते हैं। यह आज्ञाओं के निष्पादन में भी महारत हासिल करने के लिए पर्याप्त है - और कोई समस्या नहीं है। हालाँकि, यह बहुत आसान होगा। Citrix अपने vncterm टर्मिनलों में RFB प्रोटोकॉल संस्करण 003.003 का उपयोग करता है : फ़ाइल स्थानांतरण अभी तक लागू नहीं किया गया है।

इस दुखद समाचार को देखते हुए, हमारी विकास टीम ने 1998 RFB नमूने के माध्यम से परिवहन को लागू करने के संभावित तरीकों का विश्लेषण करना शुरू किया। दो विचार आए। पहला ABBYY FineReader के साथ एकीकरण है ( dom0 के साथ प्राप्त बिटमैप्स पर पाठ की मान्यता के साथ)। दूसरा माउस आंदोलनों का अनुकरण है, जो आपको स्क्रीन पर पाठ का चयन करने और प्रोटोकॉल के तहत उपलब्ध क्लिपबोर्ड पर भेजने की अनुमति देता है। नज़दीकी परीक्षा पर दोनों विकल्प, एक पागल आदमी की याद दिलाते हैं :)

निराशा की संभावनाओं ने मुझे XenAPI के लिए प्रलेखन पढ़ने के लिए वापस कर दिया। और मैंने उस पर ध्यान आकर्षित किया जो मैंने पहले नहीं देखा था - प्लग-इन आर्किटेक्चर, अर्थात्, एक आरपीसी कॉल call_plugin के माध्यम से अपने स्वयं के निष्पादन योग्य फ़ाइलों तक पहुंचने की क्षमता। मॉड्यूल /etc/xapi.d/plugins/ निर्देशिका में स्थित हैं। फिर सब कुछ सरल है: हमारे द्वारा बनाए गए प्लग-इन को एक्सएमएल-आरपीसी के माध्यम से बुलाया जाता है और उपयुक्त पायथन स्क्रिप्ट चलाता है, जो उपप्रोसेस का उपयोग करके आवश्यक कमांड के निष्पादन को लागू करता है। बहुत बढ़िया! Dom0 पर कमांड को निष्पादित करने और उनसे उत्तर प्राप्त करने की कार्यप्रणाली स्पष्ट हो गई।

अगली समस्या अपने आप दिखाई दी: सर्वर को हमारा प्लगइन कैसे मिलना चाहिए? इस समस्या को हल करने में, वास्तव में, एक्सएनएपीआई के कुछ "पानी के नीचे रेक" की खोज की गई थी ।

बेशक, मुझे फ़ंक्शन में दिलचस्पी थी, जो मानक उपयोगिता xe.exe का उपयोग करके प्राप्त की जा सकती है, - पैच-अपलोड । यह आपको XenServer पर फ़ाइलों को दूरस्थ रूप से अपलोड करने और उन्हें पूरे सर्वर पूल पर स्थापित करने की अनुमति देता है। पैच का प्रस्तुति प्रारूप काफी सरल है: यह तेज है , ज़िप में पैक किया गया है और Citrix द्वारा हस्ताक्षरित है (!)। पैच को कैसे देखना है और इसे मैन्युअल रूप से स्थापित करना है, आप कंपनी "सेलेल" के नोट में पढ़ सकते हैं। जब एक पैच डाउनलोड किया जाता है, तो उसके हस्ताक्षर को gpg कीरिंग में सार्वजनिक कुंजी के संगत सेट के साथ सत्यापित किया जाता है। इस प्रकार, अपने स्वयं के हस्ताक्षर को सामान्य बंडल में जोड़ने के लिए पर्याप्त है - और प्लग-इन कास्टिंग समस्या गायब हो जाती है। एक समान डिजाइन को इकट्ठा करना मुश्किल नहीं है, लेकिन एक गुच्छा में अपनी कुंजी को भरने के लिए आपको कंसोल तक पहुंच की आवश्यकता है। परिणाम एक दुष्चक्र था। इसलिए मैंने मानक तरीकों को दरकिनार करके अपने प्लगइन को भरने के लिए एक रास्ता तलाशना शुरू कर दिया।

इस कॉल का उपयोग करते हुए, मैंने नोट किया कि https://<xen_host>/pool_patch_upload API के आधिकारिक विवरण में नहीं है। इसके लिए एक तार्किक व्याख्या है: यह वास्तव में एपीआई का हिस्सा नहीं है। प्राकृतिक जिज्ञासा प्रश्न का संकेत देती है: “ लेकिन तब क्या है? "। उत्तर खोजने का तरीका बहुत ही सरल है: विरेचक । आप मुझे इस तरह के सीधे दृष्टिकोण के लिए दोषी ठहरा सकते हैं, लेकिन XenServer ऑपरेटिंग सिस्टम का HTTP API वर्णित है, दुर्भाग्य से, कुछ भी कम नहीं है। और जब तक मैंने इस समस्या पर काम किया, तब भी मैं OCaml को ऐसे स्तर पर नहीं समझ पाया था कि मैं स्रोत कोड का कुशलता से पर्याप्त विश्लेषण कर सकता था।

TLS को डिक्रिप्ट करने के लिए अद्भुत Wireshark सुविधा का उपयोग करना और / etc / xensource / में प्रमाणपत्र को सावधानीपूर्वक छोड़ना , मुझे xe.exe उपयोगिता (XenCenter से) और सर्वर के बीच संचार का एक डंप प्राप्त हुआ। मैं आधिकारिक दस्तावेज में वर्णित एक्सएमएल-आरपीसी संचार को देखने की उम्मीद कर रहा था। लेकिन वहाँ यह था! इसके बजाय, लॉग में "POST / cli HTTP / 1.0" चमक गया। उपयोगिता ने कमांड, इसकी विशेषताओं को लिया - और उन्हें https://<xen_host>/cli भेजा। " लगता है कि सूप में कुछ गायब है ।" यह प्रोटोकॉल के डिक्रिप्शन से निम्नानुसार है कि एक निश्चित XenSource पतली सीएलआई प्रोटोकॉल है जो उपयोगिता का उपयोग करता है। गितुब से एक्सनएपीआई के स्रोतों तक सभी रास्तों का नेतृत्व किया।

हाइपरविजर के इस अद्भुत घटक के लिए स्रोत कोड को पढ़ने के लिए कुछ समय बिताने के बाद, मुझे पता चला कि एक दिया गया है " XenSource पतली सीएलआई प्रोटोकॉल " एपीआई संस्करण 0.2 जो दूरस्थ मेजबान पर xe.exe सहायक कमांड के निष्पादन को लागू करता है। यह xapi / cli_protocol.ml फ़ाइल में वर्णित है। यह उल्लेखनीय है कि यह "भविष्य का एपीआई" है, जिसे xe.exe उपयोगिता को केवल कमांड भेजने के लिए, और XenAPI में हैंडलर के निर्माण के लिए डिज़ाइन किया गया है।

सामान्य तौर पर, इस सीएलआई एपीआई की खोज महत्वपूर्ण थी: इससे पता चला कि न केवल एक्सएमएल-आरपीसी रिसीवर और / कंसोल स्विच पोर्ट 80 \ 443 पर मौजूद हैं। समान कॉल के माध्यम से अन्य मॉड्यूल क्या उपलब्ध हैं - यह स्रोत कोड फ़ाइलों ( xen-api / ocaml / idl / constants.ml ) में से एक में पाया गया। जैसा कि आप आसानी से अनुमान लगा सकते हैं, बहुत सारी चुनौतियाँ थीं जो बहुत ही रोचक जानकारी का उत्पादन करती थीं। मुझे कॉल https://<xen-host>/syns_config_files : के साथ पर्याप्त अधिकार ( पूल-व्यवस्थापक ) मिलता है, जो आपको / etc / passwd मिलता है (जैसा कि मैंने पहले ही अपने पिछले लेखों में कहा था, XenSerif पासवर्ड हैश को स्टोर करता है)।

एक और दिलचस्प कॉल " CONNECT /remotecmd?cmd=rsync&arg=some_nice_arg &pool_secret=your_pool_secret " के माध्यम से किया गया है। यह सर्वर पर रूट विशेषाधिकारों के साथ rsync कमांड को दूरस्थ रूप से निष्पादित करने के लिए / etc / xensource / ptoken के मूल्य को जानने की अनुमति देता है। यह, संक्षेप में, फ़ाइल सिस्टम तक पूर्ण पहुंच प्रदान करता है। लेकिन आप शायद पूछें: "लेकिन पोटोकेन कैसे प्राप्त करें ?"।

यह अभी भी अधिक तुच्छ है। Xensource डेवलपर्स ने एक्सएमएल फ़ाइल के रूप में पूल डेटाबेस की सामग्री को दूरस्थ रूप से प्राप्त करने की क्षमता बनाई है। यदि आप सर्वर पर " GET /pool/xmldbdump?session_id= " फॉर्म के अनुरोध को निष्पादित करते हैं, तो आपको कुंजी-मूल्य जोड़े का एक पूरा सेट मिलेगा, जिसके बीच आप आसानी से पूल_token की आवश्यकता पा सकते हैं।

ठीक है, वास्तव में, रिमोट पैच डाउनलोड " PUT /pool_patch_upload?session_id= " कॉल के माध्यम से किया जाता है। इसके जवाब में, सर्वर लिखेगा: "200, ठीक है।" और यह इंतजार करेगा जब आप सॉकेट में बाढ़ की जानकारी देना शुरू करेंगे। जैसे ही आप फ़ाइल अपलोड करते हैं, पैच वैधता के लिए जाँचना शुरू कर देगा। लेकिन एक विशेषता है: जब आप कनेक्शन धारण कर रहे होते हैं, तो एपीआई यह मानता है कि आप अभी भी फ़ाइल अपलोड कर रहे हैं, और इसे स्पर्श नहीं करते हैं (हालाँकि फ़ाइल पहले ही / var / पैच में बनाई जा चुकी है)। मुझे नहीं मिली फ़ाइल की लंबाई के लिए जाँच करता है। चूंकि / var / पैच सर्वर के रूट सेक्शन में स्थित है, DoS अपरिहार्य है अगर / dev / urandom को वहां भेजा जाता है।

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

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