स्पोइलर: 1.11 से कम के खुले vSwitch संस्करण "फ्लड फ्लड" के हमले की चपेट में हैं, जो किसी भी वर्चुअल मशीन के पते पर अपेक्षाकृत छोटे पैकेट स्ट्रीम भेजकर एक हमलावर को नेटवर्क को बाधित करने की अनुमति देता है। संस्करण 1.11 और पुराने प्रभावित नहीं हैं। अधिकांश OVS सर्वर अभी भी OVS 1.4 या 1.9 (LTS संस्करण) का उपयोग करते हैं। ऐसे सिस्टम के प्रशासकों को OVS के नए संस्करण में अपग्रेड करने के लिए दृढ़ता से प्रोत्साहित किया जाता है।

गीत: यह एक डेढ़ साल से अधिक हो गया है क्योंकि मैं पहली बार इस समस्या को पुन: उत्पन्न करने में कामयाब रहा। शिकायत पर ओवीएस न्यूज़लेटर ने कहा कि "अगले संस्करणों में वे इसे ठीक कर देंगे" - और इसे तय किया, आधा साल बाद। हालांकि, इस फिक्स ने एलटीएस संस्करण को प्रभावित नहीं किया, जिसका अर्थ है कि ओवीएस का उपयोग करने वाले अधिकांश सिस्टम अभी भी कमजोर हैं। मैंने कई बार Citrix से संपर्क करने की कोशिश की (क्योंकि यह Xen सर्वर के हिस्से के रूप में OVS के सबसे कमजोर संस्करण का उपयोग करता है - उस समय यह शोषण का मेरा मुख्य उत्पाद था), लेकिन कोई स्पष्ट प्रतिक्रिया नहीं थी। अब प्रशासकों के पास थोड़ा रक्त के साथ समस्या को ठीक करने का अवसर है, इसलिए मैंने पुन: पेश करने के लिए बहुत आसान और समस्या का निदान करने और समस्या का निदान करने का विवरण प्रकाशित करने का निर्णय लिया - "प्रवाह भीड़" की समस्या, यह "प्रवाह बाढ़ का दौरा" भी है, यह "अजीब अज्ञात कचरा" भी है। "जिसके लिए सब कुछ अजीब तरीके से काम करता है।" पहले, इस समस्या के बारे में टिप्पणियों और मेलिंग सूचियों में, मैंने कई बार लिखा था, लेकिन मेरे पास रूसी में समस्या का पूरी तरह से वर्णन करने के लिए बारूद नहीं था, ताकि समस्या का सार सामान्य आईटी व्यक्ति को स्पष्ट हो। ठीक।

अगली पंक्ति hping3 -i u10 virtual.machine.ip वर्चुअलाइजेशन होस्ट को बाधित करती है जहां वर्चुअल मशीन चल रही है। और न केवल वर्चुअलाइजेशन होस्ट - 1.11 से कम ओपन वीस्विच संस्करणों को चलाने वाला कोई भी सिस्टम। मैं संस्करण 1.4.3 और 1.9 पर विशेष जोर देता हूं, क्योंकि वे एलटीएस संस्करण हैं और सबसे अधिक बार उपयोग किए जाते हैं।

उसी कॉल का एक और अधिक गंभीर संस्करण, इस बार नेटवर्क का उपयोग करने के लिए नियमों का उल्लंघन: hping3 --flood --rand-source virtual.machine.ip । आउटगोइंग ट्रैफ़िक का अनुपात (~ 10-60 Mbit / s) और पीड़ित के इंटरफ़ेस (2x10G) की संभावित (संभावित) बैंडविड्थ की उपलब्धता, उपलब्ध बैंड पर हमले / अटैक बैंड का अनुपात लगभग 1: 300-1: 1000 है, जो हमें भेद्यता के बारे में बात करने की अनुमति देता है, और पारंपरिक DoS हमले के बारे में नहीं। एक गैर-कार्यशील राज्य के लिए अपलिंक चैनल बाढ़, बाढ़।

वर्चुअलाइजेशन होस्ट के हिस्से पर लक्षण: कनेक्शन खोलने में अप्रत्याशित देरी, ओवीएस-वेस्विच प्रक्रिया द्वारा सीपीयू की खपत 100% तक बढ़ जाती है, नए या निष्क्रिय सत्रों के लिए पैकेट नुकसान। यदि OVS 1.4 का उपयोग किया जाता है, तो ovs-vswitchd प्रक्रिया न केवल अपने 100% CPU को खाती है, बल्कि मेमोरी को भी खाना शुरू कर देती है और इसे प्रति मिनट 20 मेगाबाइट तक की गति से करती है, जब तक कि अच्छा OOM दादा इसके पास नहीं आता है और एक शैक्षिक वार्तालाप आयोजित करता है।

सामान्य नेटवर्क की समस्याओं के विपरीत, रनिंग पिंग्स के माध्यम से "ब्रेक" होने की संभावना है, और जैसे ही प्रवाह उनके साथ कर्नेल को जाता है, पिंग बिना किसी शिकायत के काम करेगा, लेकिन यह नए कनेक्शन स्थापित करने में सक्षम नहीं होगा। यह समस्या के निदान को बहुत जटिल करता है, क्योंकि मनोवैज्ञानिक "पिंग्स हैं - नेटवर्क काम कर रहा है" से छुटकारा पाना बहुत मुश्किल है। अगर हम इसमें जोड़ते हैं कि मेजबान पर "विस्फोट" ssh सत्र बहुत अधिक कठिनाई के बिना एक ही काम करना जारी रखेगा, तो व्यवस्थापक को आश्वस्त करना कि मेजबान की नेटवर्क समस्या अत्यंत और अत्यंत कठिन होगी। यदि इंटरफ़ेस में बाढ़ एक निश्चित सीमा (~ 50-80Mb / s) से अधिक है, तो कोई भी पर्याप्त नेटवर्क गतिविधि बंद हो जाती है। लेकिन वर्णित समस्या की कपटपूर्णता इस तथ्य में निहित है कि सेवा का एक महत्वपूर्ण ह्रास काफी कम भार पर होता है, जिसके तहत विहित नेटवर्क निदान "सब कुछ क्रम में है" रिपोर्ट करता है।

मैं इस अवसर पर si14 से माफी मांगने का अवसर लेता हूं , जिन्होंने प्रयोगशाला के वर्चुअल में नेटवर्क के साथ विषमताओं के बारे में बात की थी, लेकिन उनकी उपस्थिति को साबित नहीं कर सके, लेकिन मैंने "देखा" कि मेरे साथ सब कुछ ठीक था, और इसमें एक साल से अधिक समय लगा, जब तक कि मैं अंत में केवल खुद ही नहीं हूं। संदिग्ध कुछ गलत था, लेकिन वह एक अस्पष्ट दुर्घटना परीक्षण खोजने में सक्षम था।

XenServer के मामले में, OVS के साथ स्थिति इस तथ्य से जटिल है कि स्थानीय प्रबंधन ट्रैफ़िक भी ओपन vSwitch ब्रिज से होकर जाता है, और सभी पुलों को एक ovs-vswitchd प्रक्रिया द्वारा परोसा जाता है, अर्थात्, एक खुश प्रशासक इन लक्षणों को देखने में सक्षम नहीं होगा - वे बस उसे ssh के माध्यम से नहीं जाने देंगे। । और अगर उन्होंने मुझे जाने दिया, तो ऊपर देखें, "कोई बात नहीं।" चूंकि NAS / SAN ट्रैफिक भी पुल से गुजरता है, यहां तक ​​कि कारणों के गायब होने के बाद भी, वर्चुअल मशीन निष्क्रिय रहने की संभावना है। इस मामले में, समस्या के लक्षण "एक अप्रत्याशित फ्रीज है जो लैग्स और पैकेट हानि के साथ शुरू हुआ है।"

"उत्पादन प्रबंधक" के दृष्टिकोण से भेद्यता का विवरण - एडीएसएल पर 10-50 मेगाबाइट चैनल वाला कोई भी छात्र पूरे वर्चुअलाइजेशन सर्वर फ़ार्म को दस-गीगाबिट बंदरगाहों के साथ रख सकता है, यदि कम से कम एक वर्चुअल मशीन "दिखता है" इंटरनेट पर अपने इंटरफेस के साथ। और वर्चुअल मशीन के अंदर के नियम / ACL शायद ही मदद करेंगे। किसी भी वर्चुअल मशीन का कोई भी उपयोगकर्ता इंटरनेट एक्सेस के बिना भी उसी की व्यवस्था कर सकता है।

समस्या का तकनीकी विवरण

( Openvswitch कार्यान्वयन पोस्ट के अवलोकन से चित्रण)
कारण: ओपन vwwitch के पुराने संस्करण समान प्रवाह को संयोजित करने में सक्षम नहीं हैं और जब एक ईथरनेट फ्रेम मिलता है जो नए प्रवाह के समान होता है, तो वे हमेशा नेटलिंक सॉकेट के माध्यम से निरीक्षण के लिए ovs-vswitchd प्रक्रिया में फ्रेम भेजते हैं, क्योंकि निरीक्षण प्रक्रिया बेहद धीमी होती है (हैश टेबलों की अद्भुत गति की पृष्ठभूमि के खिलाफ) कर्नेल में), और ovs-vswitchd स्वयं सिंगल-थ्रेडेड है और सिस्टम में केवल एक है, तो कई नए प्रवाह की उपस्थिति की शर्तों के तहत नेटवर्क का प्रदर्शन यूजर्सस्पेस एप्लिकेशन की गति (नेटलिंक के माध्यम से कर्नेल / बैक में जाने) की गति से सीमित प्रतीत होता है। थोड़े समय के बाद, मौजूदा कर्नेल प्रवाह को नई प्रविष्टियों द्वारा बदल दिया जाएगा और मौजूदा लोगों को बाहर कर दिया जाएगा (जब तक कि वे बहुत सक्रिय न हों), और एक नया प्रवाह बहाल करने की संभावना प्रतियोगियों की संख्या के विपरीत आनुपातिक होती है - अर्थात, बाढ़। इसके अलावा, एक शौकीन सत्र में पैकेटों की संख्या में कोई भूमिका नहीं होती है - पूरे सत्र का एकमात्र प्रवाह होता है। यह लंबे समय तक एक अंधे स्थान के रूप में परोसा जाता है - एकल टीसीपी सत्र के साथ किसी भी फट परीक्षण ने लगभग शून्य सीपीयू उपयोग के साथ यातायात के गीगाबिट्स को खुशी से सूचित किया।

कर्नेल प्रवाह बनाम ओपनफ्लो प्रवाह

कुंजी कर्नेल प्रवाह और ओपनफ्लो प्रवाह के बीच अंतर को समझने के लिए है। ओपनफ्लो प्रवाह का तात्पर्य है कि प्रवाह एक बिटमास्क के साथ है, अधिक सटीक रूप से, ओपनफ्लो प्रारूप का अर्थ है ब्याज के क्षेत्रों का संकेत। इस मामले में, शेष क्षेत्रों के लिए इसका तात्पर्य "महत्वपूर्ण नहीं" है, अर्थात "*"।

ओपन vSwitch के पुराने संस्करणों में कर्नेल मॉड्यूल नियमों के साथ काम करने के लिए एक बल्कि परिष्कृत तंत्र का उपयोग करता है, जिसमें केवल एक दोष है: यह मास्क और तारों का समर्थन नहीं करता है।

तंत्र इस प्रकार है: आने वाले ईथरनेट फ्रेम के लिए, इसके सभी हेडर को चुना जाता है, L2 से शुरू होता है और L4 के साथ समाप्त होता है (उदाहरण के लिए, TCP पोर्ट नंबर), पूरी तरह से बेकार लोगों को, टीसीपी के "विंडो आकार" या "खंड संख्या" की तरह। "। उन सभी को एक द्विआधारी संरचना में पैक किया जाता है, जिसके बाद इस संरचना से एक हैश माना जाता है। अगला, इस हैश को नियमों के हैश तालिका में देखा जाता है, और यदि नियम के लिए कोई मेल है, तो इसका उपयोग किया जाता है। यदि कोई भी मेल नहीं खाता है, तो पैकेज को यूजर्सस्पेस (ovs-vswitchd) में एक अधिक बुद्धिमान कार्यक्रम के निरीक्षण के लिए भेजा जाता है, जो इस तरह के पैकेज के साथ क्या करना है, इस पर एक नया नियम भेजता है। ओपनफ्लो के नियम, साथ ही ओवेस-ऑफक्टल के माध्यम से मैन्युअल रूप से लगाए गए नियम बिल्कुल ओवस-वेस्विच द्वारा संसाधित किए जाते हैं, और कर्नेल मॉड्यूल उनके बारे में कुछ भी नहीं जानता है। यह "सामान्य" नियम के लिए विशेष रूप से सच है, जिसका अर्थ है "स्विच की तरह कार्य करना।" लेकिन यहां तक ​​कि एक सामान्य बूंद को अभी भी उपयोगकर्ता-अंतरिक्ष में निरीक्षण की आवश्यकता होती है, क्योंकि ड्रॉप सबसे अक्सर आवक / आउटगोइंग पोर्ट के सभी संभावित संयोजनों को शामिल नहीं करता है, और इसलिए, ओवीएस के दृष्टिकोण से इसमें तारांकन शामिल हैं।

एक हैश तालिका शानदार प्रदर्शन देती है जो नियमों की संख्या पर निर्भर नहीं करती है (यानी, 10,000 नियमों को एक ही गति के बारे में संसाधित किया जाएगा)।

दुर्भाग्य से, यदि प्रत्येक नए पैकेज के हेडर्स अलग हैं, तो प्रत्येक नया ऐसा पैकेज यूजरस्पेस में निरीक्षण के लिए जाएगा। जो धीमा और दुखद है।

ओवीएस का मूल विचार यह था कि एक टीसीपी सत्र के भीतर सभी पैकेट समान होंगे और पूरे सत्र के लिए एक नियम होगा। दुर्भाग्य से, बुराई "हकीकी वास्या", ऊपर की रेखा की नकल करके, इस उम्मीद को तोड़ने में सक्षम होगी।

नए संस्करणों में, इस समस्या को मेगाफ्लो का उपयोग करके हल किया गया था।

Megaflow

वे संस्करण 1.11 से ओपन वीस्विच में दिखाई दिए हैं। मेगाफ्लो ओपनफ्लो से संबंधित नहीं है, लेकिन ओवस-वेस्विच और कर्नेल मॉड्यूल के संपर्क की चिंता करता है। दुर्भाग्य से, मेगाफ्लो की कीमत काफी ठोस है - कुछ मामलों में प्रदर्शन 5-20% तक गिर जाता है। सौभाग्य से, बदले में, ovs-vswitchd किसी भी परिस्थिति में संसाधनों की अनुपातहीन मात्रा में नहीं खाएगा।

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

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

जंगली में हमला

इस तथ्य के बावजूद कि लेख की शुरुआत में यह "हिप्पिंग / नैपिंग के साथ सेवा हमले से इनकार" के बारे में था, वास्तविक समस्या बहुत व्यापक है। यदि किसी कारण से वर्चुअल मशीन पर कई अलग-अलग पते से कॉल आते हैं, या कई सत्र बस स्थापित होते हैं, तो ओवीएस व्यवहार के दृष्टिकोण से "हमले" और "उच्च भार" के साथ कोई अंतर नहीं है। मैंने इसे वास्तविकता में देखा था जब एक आभासी मशीन का उपयोग कुछ तस्वीरों के लिए बहुत ही लोकप्रिय ब्राउज़र गेम के लिए स्टैटिक्स वितरित करने के लिए किया गया था। कई खिलाड़ी थे, कई चित्र थे, वे छोटे थे। कुल - 300-500 बाइट्स के आकार में प्रति सेकंड कई हजार नए टीसीपी सत्र। इस मामले में, 15-20 मेगाबिट्स का बहुत मध्यम प्रवाह प्राप्त किया गया था। और OVS के पुराने संस्करणों के लिए सबसे खराब स्थिति है, क्योंकि प्रत्येक सत्र उपयोगकर्ता स्थान पर जा रहा है।

एक अतिरिक्त समस्या यह है कि नेटलिंक में एक बफर है, और नेटवर्क इंटरफेस में एक बफर है, और ओवीएस में एक बफर है। आने वाले पैकेट केवल ड्रॉप नहीं करते हैं - वे कतार लगाते हैं, प्रोसेसर को 100% लोड करते हैं (हाँ, 800 में से 100 उपलब्ध हैं)। इससे नए प्रवाह के प्रसंस्करण में विलंबता बढ़ जाती है। इसके अलावा, इस विलंबता का निदान करना बेहद मुश्किल है: अंतराल केवल पहले पैकेट पर है, सभी बाद वाले (निर्मित प्रवाह के ढांचे के भीतर) जल्दी से संसाधित होते हैं।

विलंबता में वृद्धि समस्या के दूसरे हिस्से की ओर ले जाती है: यदि मौजूदा टीसीपी सत्र का एक पैकेट कतार में काफी लंबा है, तो इस तरह के सत्र के बारे में रिकॉर्ड कर्नेल प्रवाह तालिका से मिटा दिया जाता है। और पैकेज फिर से निरीक्षण में चला जाता है, एक नया कर्नेल प्रवाह बनाने के लिए, और यह आगे OVS को "सांस लेने और नहीं हिलने" की स्थिति में ले जाता है।

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

यह स्पष्ट है कि इस तरह की मृत्यु एक सार्वजनिक प्रदाता के लिए समान है। अपने पिछले काम में, मुझे एक बल्कि बदसूरत पैच लिखना था जिसने ओवीएस की अधिकांश कार्यक्षमता में कटौती की (क्योंकि उस समय मेगाफ्लो वहां नहीं था), बाइनरी फिंगरप्रिंट्स (जिसमें से हैश बनाया गया है) के केवल सबसे छोटे संभव सेट को छोड़कर। वे इसे अपस्ट्रीम पर नहीं ले जाते, लेकिन मैंने समस्या हल कर दी। और मेगाफ़्लो के साथ OVS 1.11 की रिलीज़ से पहले, लगभग आधा साल रहा ...

समस्या का परिमाण

वितरण किट	OVS संस्करण	भेद्यता
डेबियन सकीज़	एक्स	कोई पैकेज नहीं
डेबियन व्हीजी	1.4.2	कमजोर संस्करण + स्मृति रिसाव
डेबियन सिड	1.9.3	कमजोर संस्करण (यहां आपके पास खून बह रहा है)
उबुन्टु 12.04	1.4	कमजोर संस्करण + स्मृति रिसाव
उबंटू 14.04	2.0	चीयर्स, चीयर्स।
ज़ेनसर 5.5	1.4.2	कमजोर संस्करण + स्मृति रिसाव
ज़ेनसर्वर 6.2	1.4.3	कमजोर संस्करण। अब तक, 1.9 भी नहीं!
आरएचईएल / सेंटोस 5	एक्स	पैकेज प्रदान नहीं किया गया
रेडहैट / सेंटोस 6.5	एक्स	कर्नेल मॉड्यूल केवल, बिना यूजरस्पेस के
फेडोरा 21	2.1	सबसे ताज़ा!

(आपके पसंदीदा वितरण में OVS संस्करण के बारे में जानकारी स्वागत योग्य है और इसे जोड़ा जाएगा; यह वितरण वेबसाइट के लिंक के साथ संस्करण को इंगित करना उचित है)
चूंकि ओवीएस ओपनस्टैक के लिए अनुशंसित और मानक पुल है, जिसमें ओपन सोर्स संस्करण और कई मालिकाना वाले हैं (वे अभी भी वर्चुअल मशीनों के लिए ट्रैफिक के लिए ओवीएस का उपयोग करते हैं), हम कह सकते हैं कि अधिकांश डिफॉल्ट ओपनस्टैक इंस्टॉलेशन समस्या से ग्रस्त हैं। इसी तरह की समस्या OVS पर आधारित libvirt की पूर्णकालिक स्थापना की उम्मीद करती है - चूंकि वितरण मुख्य रूप से समस्याग्रस्त संस्करण हैं।

निष्कर्ष

अद्यतन, अद्यतन, अद्यतन। CentOS 5 उपयोगकर्ताओं और अन्य विशाल उत्साही लोगों के लिए सौभाग्य से, OVS 1.11 कर्नेल मॉड्यूल 2.6.18 (लेकिन 3.8 से अधिक नहीं) का समर्थन करता है, इसलिए यह अधिकांश प्रणालियों पर काम करेगा। नई गुठली के लिए, यह OVS के नए संस्करणों का उपयोग करने के लायक है - 2.0, या यहां तक ​​कि 2.1 (बस मई 2014 की शुरुआत में जारी)। प्रमुख संभावित समस्या यह है कि यदि आप ओवीएस को अपडेट करते समय कर्नेल मॉड्यूल को अपडेट नहीं करते हैं, तो परिणामस्वरूप परिणाम काम नहीं करेगा (हालांकि कमांड-लाइन उपयोगिताओं कार्य क्षमता को चित्रित करने का प्रयास करेगी)।

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

संबंधित लिंक :

• विकिपीडिया लेख: en: ओपन vSwitch , en: ओपन vSwitch , en: OpenFlow , en: OpenFlow
• ओपन vSwitch डाउनलोड करें
• ओपन vSwitch आर्किटेक्चर वीडियो
• OVS फ्लो प्रोसेसिंग मैनेजमेंट मैनुअल

PS यदि कोई व्यक्ति वर्चुअल मशीन से "यह कैसे काम करता है" जाँचने का निर्णय लेता है - ध्यान रखें कि शुरू करने के बाद यह संभावना है कि आप Ctrl-C नहीं दबाएंगे। अधिक सटीक रूप से, दबाएं, लेकिन सर्वर आपको नहीं सुनेगा और इंटरफ़ेस को बाढ़ भेजना जारी रखेगा, और यहां तक ​​कि इस तरह की वर्चुअल मशीन को रिबूट करना भी मुश्किल होगा - यदि नियंत्रण एक ही पुल से गुजरता है, तो शटडाउन या रिबूट कमांड मेजबान पर उपयोगिताओं "बस" पहुंच जाएगा।