Cloudflare क्रैश विवरण 2 जुलाई 2019

लगभग 9 साल पहले, Cloudflare एक छोटी कंपनी थी, लेकिन मैंने इसमें काम नहीं किया, मैं सिर्फ एक ग्राहक था। Cloudflare को लॉन्च करने के एक महीने बाद, मुझे एक सूचना मिली कि DNS मेरी jgc.org वेबसाइट पर काम नहीं कर रहा है। क्लाउडफ्लेयर ने प्रोटोकॉल बफ़र्स में बदलाव किया, और एक टूटा हुआ डीएनएस था।

मैंने तुरंत मैथ्यू प्रिंस को पत्र लिखा, "मेरा डीएनएस कहां है?", और उन्होंने एक लंबा जवाब भेजा, तकनीकी विवरणों से भरा ( यहां सभी पत्राचार पढ़ें ), जिसके लिए मैंने उत्तर दिया:

से: जॉन ग्राहम कमिंग
दिनांक: 7 अक्टूबर, 2010 9:14
विषय: रे: मेरा डीएनएस कहां है?
टू: मैथ्यू प्रिंस

कूल रिपोर्ट, धन्यवाद। समस्या होने पर जरूर फोन करूंगा। जब आप सभी तकनीकी जानकारी एकत्र करते हैं, तो संभवतः इस बारे में एक पोस्ट लिखने के लायक है। मुझे लगता है कि लोगों को एक खुली और ईमानदार कहानी पसंद आएगी। खासतौर पर अगर आप ग्राफिक्स को यह दिखाने के लिए संलग्न करते हैं कि लॉन्च के बाद ट्रैफिक कैसे बढ़ा।

साइट पर मेरी अच्छी निगरानी है, और मुझे प्रत्येक विफलता के बारे में एक एसएमएस प्राप्त होता है। निगरानी से पता चलता है कि विफलता 13:03:07 से 14:04:12 तक थी। हर पांच मिनट में टेस्ट आयोजित किए जाते हैं।

मुझे यकीन है कि आप इसका पता लगा लेंगे। आप निश्चित रूप से यूरोप में अपने व्यक्ति की जरूरत नहीं है? :-)

और उसने उत्तर दिया:

प्रेषक: मैथ्यू प्रिंस
दिनांक: 7 अक्टूबर, 2010, 9:57
विषय: रे: मेरा डीएनएस कहां है?
टू: जॉन ग्राहम कमिंग

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

अब Cloudflare एक बहुत बड़ी कंपनी है, मैं इसमें काम करता हूं, और अब मुझे अपनी गलती, इसके परिणाम और हमारे कार्यों के बारे में खुलकर लिखना होगा।

2 जुलाई की घटना

2 जुलाई को, हमने WAF के लिए प्रबंधित नियमों में एक नया नियम लागू किया, जिसके कारण प्रोसेसर संसाधन प्रत्येक प्रोसेसर कोर पर चले गए जो कि दुनिया भर में क्लाउडफेयर नेटवर्क पर HTTP / HTTPS ट्रैफ़िक को संसाधित करता है। हम नई कमजोरियों और खतरों के जवाब में WAF के लिए प्रबंधित नियमों में लगातार सुधार कर रहे हैं। मई में, उदाहरण के लिए, हम SharePoint में एक गंभीर भेद्यता से खुद को बचाने के लिए एक नियम जोड़ने के लिए पहुंचे। हमारे WAF का पूरा बिंदु त्वरित और विश्व स्तर पर तैनात नियमों की क्षमता है।

दुर्भाग्य से, पिछले गुरुवार को अद्यतन में एक नियमित अभिव्यक्ति शामिल थी जो बहुत सारे प्रोसेसर संसाधनों को HTTP / HTTPS को बैकट्रैकिंग पर समर्पित करती थी। इससे हमारी कोर प्रॉक्सी, CDN और WAF सुविधाएँ प्रभावित हुईं। ग्राफ से पता चलता है कि HTTP / HTTPS ट्रैफ़िक की सेवा के लिए प्रोसेसर संसाधन हमारे नेटवर्क में सर्वरों पर लगभग 100% तक पहुंचते हैं।

एक घटना के दौरान उपस्थिति के एक बिंदु पर प्रोसेसर संसाधनों का उपयोग करना

परिणामस्वरूप, हमारे ग्राहक (और हमारे ग्राहकों के ग्राहक) क्लाउडफ़ेयर डोमेन में 502 त्रुटि के साथ एक पृष्ठ पर चले गए। क्लाउडफेयर फ्रंट-एंड वेब सर्वरों द्वारा 502 त्रुटियां उत्पन्न की गईं, जिनमें अभी भी मुक्त कोर थे, लेकिन वे HTTP / HTTPS ट्रैफिक को प्रोसेस करने वाली प्रक्रियाओं के साथ संवाद नहीं कर सके।

हम जानते हैं कि इससे हमारे ग्राहकों को कितनी असुविधाएँ हुईं। हमें बहुत शर्म आती है। और इस विफलता ने हमें घटना से प्रभावी ढंग से निपटने से रोका।

यदि आप इन ग्राहकों में से एक थे, तो यह शायद आपको डरा, नाराज और परेशान कर दे। इसके अलावा, हमारे पास 6 साल से वैश्विक विफलताएं नहीं हैं। उच्च सीपीयू खपत एक WAF नियम के कारण खराब रूप से तैयार नियमित अभिव्यक्ति के साथ था, जिसके कारण अत्यधिक बैकट्रैकिंग हो गई थी। यहाँ दोषी अभिव्यक्ति है: (?:(?:\"|'|\]|\}|\\|\d|(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))

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

क्या हुआ?

चलिए शुरू करते हैं। सभी समय यूटीसी में इंगित किया गया है।

13:42 पर, फ़ायरवॉल टीम के एक इंजीनियर ने एक स्वचालित प्रक्रिया का उपयोग करके XSS का पता लगाने के नियमों में एक छोटा सा बदलाव किया। तदनुसार, एक परिवर्तन अनुरोध टिकट बनाया गया था। हम जीरा (नीचे स्क्रीनशॉट) के माध्यम से इन टिकटों का प्रबंधन करते हैं।

3 मिनट के बाद, पहला PagerDuty पृष्ठ दिखाई दिया, WAF के साथ एक समस्या की रिपोर्ट करना। यह एक सिंथेटिक परीक्षण था जो सामान्य ऑपरेशन की निगरानी के लिए क्लाउडफेयर के बाहर WAF (हम उनमें से सैकड़ों) की कार्यक्षमता की जांच करता है। फिर तुरंत ही दुनिया भर के शहरों में क्लाउडफ़ेयर सेवाओं की अन्य अंत-टू-एंड परीक्षणों की विफलता, वैश्विक ट्रैफ़िक समस्याओं, व्यापक 502 त्रुटियों और हमारी मौजूदगी के बिंदुओं (पीओपी) से रिपोर्टों के एक समूह की सूचनाओं के साथ पृष्ठ थे, जिन्होंने प्रोसेसर संसाधनों की कमी का संकेत दिया था।

मुझे ऐसी कई सूचनाएं मिलीं, बैठक से बाहर हो गए और पहले से ही मेज पर चल रहे थे जब हमारे समाधान विकास विभाग के प्रमुख ने कहा कि हमने 80% यातायात खो दिया है। मैं हमारे एसआरई इंजीनियरों के पास गया, जो पहले से ही समस्या पर काम कर रहे थे। पहले तो हमें लगा कि यह किसी तरह का अज्ञात हमला है।

Cloudflare SRE के इंजीनियर दुनिया भर में बिखरे हुए हैं और घड़ी की स्थिति पर नज़र रखते हैं। आमतौर पर, ऐसे अलर्ट आपको सीमित दायरे की विशिष्ट स्थानीय समस्याओं के बारे में सूचित करते हैं, आंतरिक डैशबोर्ड पर नजर रखी जाती है और दिन में कई बार हल की जाती है। लेकिन ऐसे पृष्ठों और सूचनाओं ने वास्तव में कुछ गंभीर होने का संकेत दिया, और एसआरई इंजीनियरों ने तुरंत P0 गंभीरता स्तर की घोषणा की और प्रबंधन और सिस्टम इंजीनियरों की ओर मुड़ गए।

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

14:00 बजे हमने निर्धारित किया कि WAF के साथ कोई समस्या थी और कोई हमला नहीं हुआ। प्रदर्शन विभाग ने प्रोसेसर डेटा पुनर्प्राप्त किया, और यह स्पष्ट हो गया कि WAF को दोष देना था। एक अन्य सहयोगी ने इस सिद्धांत की पुष्टि स्ट्रेस के साथ की। किसी और ने लॉग्स में देखा कि WAF के साथ परेशानी। 14:02 पर, पूरी टीम मेरे पास आई, जब इसे वैश्विक मार का उपयोग करने का प्रस्ताव दिया गया था - क्लाउडफेयर में बनाया गया एक तंत्र जो दुनिया भर में एक घटक को निष्क्रिय करता है।

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

और हम अपनी आंतरिक सेवाओं जैसे जीरा या बिल्ड सिस्टम से नहीं मिल सके। हमें एक वर्कअराउंड की आवश्यकता थी, जिसे हम बार-बार उपयोग करते थे (इसे भी काम करने की आवश्यकता होगी)। अंत में, एक इंजीनियर 14:07 पर WAF को काट सकता था, और 14:09 पर हर जगह यातायात और प्रोसेसर का स्तर सामान्य हो गया। क्लाउडफ़ेयर के बाकी रक्षा तंत्र ने उम्मीद के मुताबिक काम किया।

फिर हमने WAF को बहाल करने के बारे में सेट किया। स्थिति सामान्य से बाहर थी, इसलिए हमने अलग-अलग ट्रैफ़िक का उपयोग करके, वहां से भुगतान किए गए ग्राहकों को स्थानांतरित करके एक शहर में नकारात्मक परीक्षण किए (स्वयं से पूछें कि क्या समस्या वास्तव में यह परिवर्तन था) और सकारात्मक (रोलबैक ने काम किया)।

दोपहर 2:52 बजे हम आश्वस्त थे कि हमने इसका कारण समझा और सुधार किया और फिर से WAF चालू कर दिया।

कैसे Cloudflare काम करता है

Cloudflare में इंजीनियरों की एक टीम है जो WAF के लिए प्रबंधित नियमों का प्रबंधन करती है। वे पता लगाने की दर को बढ़ाने की कोशिश करते हैं, झूठी सकारात्मकता की संख्या को कम करते हैं और नए खतरों का तुरंत जवाब देते हैं। पिछले 60 दिनों में, WAF प्रबंधित नियमों के लिए 476 परिवर्तन अनुरोध संसाधित किए गए हैं (औसतन, हर 3 घंटे में)।

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

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

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

यदि असेंबली और परीक्षण सफल होते हैं, तो जीरा में एक परिवर्तन अनुरोध बनाया जाता है, और परिवर्तन को उचित पर्यवेक्षक या लीड विशेषज्ञ द्वारा अनुमोदित किया जाना चाहिए। अनुमोदन के बाद, इसे तथाकथित "PoP menagerie": DOG, PIG और कैनरी (कुत्ता, गेंदा और कैनरी) में तैनात किया जाता है।

DOG PoP Cloudflare PoP (हमारे शहरों के किसी भी अन्य की तरह) है, जो केवल Cloudflare कर्मचारियों द्वारा उपयोग किया जाता है। आंतरिक उपयोग के लिए पीओपी आपको ग्राहक ट्रैफ़िक प्राप्त करने के लिए समाधान शुरू होने से पहले ही समस्याओं को पकड़ने की अनुमति देता है। उपयोगी बात।

यदि DOG परीक्षण सफल होता है, तो कोड PIG चरण (गिनी पिग) में आगे बढ़ता है। यह क्लाउडफ्लारे पीओपी है, जहां नए कोड के माध्यम से मुफ्त क्लाइंट ट्रैफ़िक की थोड़ी मात्रा बहती है।
यदि सब कुछ ठीक है, तो कोड कैनरी में चला जाता है। हमारे पास दुनिया के विभिन्न हिस्सों में तीन कैनरी PoP हैं। पेड और फ्री क्लाइंट्स का ट्रैफ़िक उनमें नए कोड से होकर गुजरता है, और यह अंतिम त्रुटि जांच है।

Cloudflare सॉफ़्टवेयर रिलीज़ प्रक्रिया

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

खतरा वाफ़
पिछले कुछ वर्षों में, पारंपरिक अनुप्रयोगों में काफी अधिक खतरे हैं। यह सॉफ्टवेयर परीक्षण उपकरणों की अधिक उपलब्धता के कारण है। उदाहरण के लिए, हमने हाल ही में फ़ज़िंग के बारे में लिखा है)।

स्रोत: https://cvedetails.com/

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

Cloudflare की त्वरित प्रतिक्रिया का एक शानदार उदाहरण मई में SharePoint भेद्यता संरक्षण की तैनाती है ( यहां पढ़ें )। विज्ञापनों के प्रकाशन के लगभग तुरंत बाद, हमने अपने ग्राहकों की SharePoint स्थापनाओं में भेद्यता के दोहन के प्रयासों की एक बड़ी संख्या पर ध्यान दिया। हमारे लोग लगातार नए खतरों की निगरानी करते हैं और अपने ग्राहकों की सुरक्षा के लिए नियम लिखते हैं।

गुरुवार को समस्या का कारण बना नियम क्रॉस-साइट स्क्रिप्टिंग (XSS) से बचाव करना था। हाल के वर्षों में ऐसे कई और हमले हुए हैं।

स्रोत: https://cvedetails.com/

WAF के लिए एक प्रबंधित नियम को संशोधित करने के लिए मानक प्रक्रिया को वैश्विक तैनाती से पहले निरंतर एकीकरण परीक्षण (CI) की आवश्यकता होती है। पिछले गुरुवार को, हमने इसे किया और नियमों का विस्तार किया। 13:31 पर, एक इंजीनियर ने एक बदलाव के साथ एक स्वीकृत पूल अनुरोध भेजा।

13:37 पर, टीमसिटी ने नियमों को इकट्ठा किया, परीक्षणों को चलाया और आगे बढ़ दिया। WAF परीक्षण सूट WAF कोर कार्यक्षमता का परीक्षण करता है और इसमें व्यक्तिगत कार्यों के लिए बड़ी संख्या में यूनिट परीक्षण होते हैं। इकाई परीक्षणों के बाद, हमने भारी संख्या में HTTP अनुरोधों के साथ WAF के नियमों की जाँच की। HTTP अनुरोधों की जांच करता है कि कौन से अनुरोधों को WAF (हमले को रोकने के लिए) द्वारा अवरुद्ध किया जाना चाहिए और जिसे छोड़ दिया जा सकता है (ताकि सब कुछ अवरुद्ध न हो और झूठी सकारात्मकता से बचा जा सके)। लेकिन हमने प्रोसेसर संसाधनों के अत्यधिक उपयोग के लिए परीक्षण नहीं किया था, और पिछले WAF विधानसभाओं के लॉग का अध्ययन करने से पता चलता है कि नियम के साथ परीक्षण निष्पादन समय में वृद्धि नहीं हुई थी, और यह संदेह करना मुश्किल था कि पर्याप्त संसाधन नहीं थे।

परीक्षण पारित किए गए, और टीमकीट ने स्वचालित रूप से 13:42 पर परिवर्तन को तैनात करना शुरू कर दिया।

पारा

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

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

कॉन्फ़िगरेशन के लिए दुनिया भर में डैशबोर्ड पर एक बटन दबाने से या कॉन्फ़िगरेशन परिवर्तन करने के लिए API कॉल करने में केवल कुछ सेकंड लगते हैं। ग्राहकों को यह गति सेटिंग पसंद है। और श्रमिक उन्हें लगभग तत्काल वैश्विक सॉफ्टवेयर परिनियोजन प्रदान करते हैं। औसतन, क्विकसिल्वर प्रति सेकंड लगभग 350 बदलाव वितरित करता है।

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

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

नियमों को लागू करने से पहले, सब कुछ सुचारू रूप से चला गया: पूल अनुरोध बनाया गया था और अनुमोदित किया गया था, CI / CD पाइपलाइन को संकलित और कोड का परीक्षण किया गया था, परिवर्तन अनुरोध को एसओपी के अनुसार भेजा गया था, जो तैनाती और रोलबैक को नियंत्रित करता है, और तैनाती पूरी हो गई थी।

CloudFare WAF परिनियोजन प्रक्रिया

क्या गलत हुआ?
जैसा कि मैंने पहले कहा था, हम हर हफ्ते दर्जनों नए डब्ल्यूएएफ नियमों को तैनात करते हैं, और हमारे पास ऐसी तैनाती के नकारात्मक परिणामों के खिलाफ कई सुरक्षा प्रणालियां हैं। और जब कुछ गलत होता है, तो यह आमतौर पर कई परिस्थितियों का एक संयोजन होता है। यदि आप केवल एक कारण पाते हैं, तो यह निश्चित रूप से शांत है, लेकिन हमेशा सच नहीं है। यहाँ कारण हैं कि एक साथ हमारी HTTP / HTTPS सेवा की विफलता के कारण।

1. अभियंता ने एक नियमित अभिव्यक्ति लिखी जिससे अत्यधिक पिछड़ापन हो सकता है।
2. एक उपकरण जो नियमित अभिव्यक्ति द्वारा उपयोग किए जाने वाले प्रोसेसर संसाधनों के अत्यधिक उपयोग को रोक सकता है, उसे कुछ हफ्तों पहले WAF के दौरान गलती से हटा दिया गया था - Refactoring की आवश्यकता थी ताकि WAF कम संसाधनों का उपभोग करे।
3. रेगेक्स इंजन में जटिलता की कोई गारंटी नहीं थी।
4. परीक्षण सूट अत्यधिक सीपीयू की खपत को उजागर नहीं कर सका।
5. एसओपी प्रक्रिया बहु-चरण प्रक्रिया के बिना गैर-आवश्यक नियम परिवर्तनों की वैश्विक तैनाती को सक्षम करती है।
6. रोलबैक योजना को दो बार पूर्ण WAF विधानसभा की आवश्यकता थी, जिसमें एक लंबा समय लगा।
7. पहले वैश्विक यातायात चेतावनी अलर्ट ने बहुत देर से काम किया।
8. हमने स्थिति पृष्ठ अपडेट करने में देरी की।
9. हमें क्रैश के कारण सिस्टम तक पहुँचने में समस्याएँ थीं, और वर्कअराउंड पर पर्याप्त रूप से काम नहीं किया गया था।
10. SRE इंजीनियरों ने कुछ प्रणालियों तक पहुंच खो दी है क्योंकि सुरक्षा कारणों से उनकी साख समाप्त हो गई है।
11. हमारे ग्राहकों के पास क्लाउडफ़ेयर डैशबोर्ड या API तक पहुंच नहीं है क्योंकि वे क्लाउडफ़ेयर क्षेत्र से गुजरते हैं।

पिछले गुरुवार से क्या बदल गया है

सबसे पहले, हमने WAF के लिए रिलीज पर सभी काम पूरी तरह से रोक दिया और निम्नलिखित कार्य करें:

1. अत्यधिक प्रोसेसर संसाधनों के खिलाफ सुरक्षा को फिर से पेश करना, जिन्हें हमने हटा दिया। (समाप्त)
2. अत्यधिक बैकट्रैकिंग के अन्य संभावित मामलों को खोजने और ठीक करने के लिए WAF के लिए प्रबंधित नियमों में सभी 3868 नियमों को मैन्युअल रूप से जांचें। (सत्यापन पूरा हुआ)
3. हम परीक्षण सूट में सभी नियमों के लिए प्रदर्शन रूपरेखा शामिल करते हैं। (अपेक्षित: 19 जुलाई)
4. हम re2 या Rust regex इंजन पर जाते हैं - दोनों रनटाइम में गारंटी प्रदान करते हैं। (अपेक्षित: 31 जुलाई)
5. हम क्लाउड में अन्य सॉफ्टवेयर की तरह चरणों में नियमों को तैनात करने के लिए एसओपी को फिर से लिखते हैं, लेकिन साथ ही साथ वैश्विक तैनाती को आपातकालीन करने की क्षमता है अगर हमले पहले ही शुरू हो गए हैं।
6. हम क्लाउडफेयर डैशबोर्ड और एपीआई की क्लाउड क्लाउड क्षेत्र से तत्काल वापसी की संभावना विकसित कर रहे हैं।
7. हम क्लाउडफ़ेयर स्थिति पृष्ठ के अपडेट को स्वचालित कर रहे हैं।

लंबे समय में, हम Lua WAF को छोड़ रहे हैं, जो मैंने कई साल पहले लिखा था। हम WAF को नए फ़ायरवॉल सिस्टम में माइग्रेट करते हैं। तो WAF तेज़ होगा और सुरक्षा का एक अतिरिक्त स्तर प्राप्त करेगा।

निष्कर्ष

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

हमें इस विफलता पर बहुत शर्म आती है, और हम अपने ग्राहकों से माफी मांगते हैं। हमें उम्मीद है कि ये बदलाव सुनिश्चित करेंगे कि ऐसा दोबारा न हो।

आवेदन। नियमित अभिव्यक्ति बैकट्रैकिंग

यह समझने के लिए कि अभिव्यक्ति कैसे है:

 (?:(?:\"|'|\]|\}|\\|\d (?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\- |\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*))) 

सभी प्रोसेसर संसाधनों को खा लिया, आपको थोड़ा पता होना चाहिए कि मानक रेगेक्स इंजन कैसे काम करता है। यहाँ समस्या पैटर्न है .*(?:.*=.*) । (?: और संबंधित एक ) एक रोमांचक समूह नहीं है (यानी, कोष्ठक में अभिव्यक्ति को एक अभिव्यक्ति के रूप में वर्गीकृत किया गया है)।

प्रोसेसर संसाधनों की अत्यधिक खपत के संदर्भ में, इस पैटर्न को .*.*=.* रूप में नामित किया जा सकता है। जैसे, पैटर्न अनावश्यक रूप से जटिल दिखता है। लेकिन इससे भी महत्वपूर्ण बात यह है कि वास्तविक दुनिया में, ऐसी अभिव्यक्तियाँ (WAF नियमों में जटिल अभिव्यक्तियों के समान) जो इंजन को एक टुकड़े से मेल खाने के लिए कहती हैं, जिसके परिणामस्वरूप एक और टुकड़ा हो सकता है। और यहाँ क्यों है।

नियमित अभिव्यक्ति में . इसका मतलब है कि आपको किसी एक वर्ण से मेल खाना है .*.*=.* शाब्दिक वर्ण =, शून्य या अधिक वर्णों से मेल खाता है।

टेस्ट लाइन x=x । यह अभिव्यक्ति से मेल खाता है .*.*=.*. .*.* .*.*=.*. .*.* बराबर चिह्न तक पहले x (समूहों में से एक) से मेल खाती है .* x मेल खाती है, और दूसरा से शून्य वर्ण)। .* बाद = अंतिम x मेल खाता है।

ऐसी तुलना के लिए, 23 चरणों की आवश्यकता है। पहला समूह .* .*.*=.* "लालच" से काम करता है और पूरी लाइन x=x मेल खाता है। इंजन अगले समूह में चला जाता है .* । हमारे पास अब मिलान करने के लिए वर्ण नहीं हैं, इसलिए दूसरा समूह .* शून्य वर्णों से मेल खाता है (यह अनुमति है)। तब इंजन = चिन्ह पर जाता है। कोई और वर्ण नहीं हैं (पहला समूह .* पूरी अभिव्यक्ति x=x ), कोई मिलान नहीं होता है।

और यहां नियमित अभिव्यक्ति इंजन शुरुआत में लौटता है। वह पहले समूह में जाता है .* और इसकी तुलना x= ( x=x बजाय) से करता है, और फिर दूसरे समूह पर ले जाता है .* दूसरा समूह .* दूसरे x नक्शे, और फिर से हमारे पास कोई वर्ण नहीं बचा है। और जब इंजन = v .*.*=.* पहुंचता है, तो फिर कुछ नहीं होता है। और वह फिर से पीछे हटता है।

इस बार, समूह .* फिर भी x= मेल खाता है, लेकिन दूसरा समूह .* अब x , बल्कि शून्य वर्ण है। इंजन शाब्दिक प्रतीक = पैटर्न में खोजने की कोशिश करता है .*.*=.* , लेकिन बाहर नहीं निकलता (आखिरकार, पहले समूह ने पहले ही कब्जा कर लिया है .* )। और वह फिर से पीछे हटता है।

इस बार पहला समूह .* केवल पहला एक्स लेता है। लेकिन दूसरा समूह .* "लालची" =x पकड़ता है। पहले से ही अनुमान लगाया कि क्या होगा? इंजन शाब्दिक रूप से मेल खाने की कोशिश करता है = , विफल रहता है और अगला बैकट्रैकिंग करता है।

.* x . .* = . , = , .* . . !

.* x , .* — , = = . .* x .

23 x=x . Perl Regexp::Debugger , , .

, x=x x=xx ? 33 . x=xxx ? 45. . x=x x=xxxxxxxxxxxxxxxxxxxx (20 x = ). 20 x = , 555 ! ( , x= 20 x , 4067 , , ).

x=xxxxxxxxxxxxxxxxxxxx :

, . , . , .*.*=.* ; ( ). , , foo=bar; ।

. x=x 90 , 23. . x= 20 x , 5353 . . Y .

, 5353 x=xxxxxxxxxxxxxxxxxxxx .*.*=.*;

«», «» , . .*?.*?=.*? , x=x 11 ( 23). x=xxxxxxxxxxxxxxxxxxxx . , ? .* , .

«» . .*.*=.*; .*?.*?=.*?; , . x=x 555 , x= 20 x — 5353.

, ( ) — . .

1968 , Programming Techniques: Regular expression search algorithm (« : »). , , , .

(Ken Thompson)
Bell Telephone Laboratories, Inc., -, -

. IBM 7094 . , . , .


, .

. . — .
. , . , .
, IBM 7094.


. — , . «·» . . . 2 , .

, ALGOL-60, IBM 7094. , .

. ⊕ .
1 . — a, b, c, S[i] NNODE.

NNODE , (. . 5)

.*.*=.* , , .

. 0 , 0, 3 , 1, 2 3. .* . 3 . = = . 4 . , .

, .*.*=.* , x=x . 0, . 1।

, . .

, (1 2), . 2।

. 2 , , x x=x . x , 1 1. x , 2 2.

x x=x - 1 2. 3 4, = .

= x=x . x , 1 1 2 2, = 2 3 ( 4). . 3।

x x=x . 1 2 1 2. 3 x 3.

x=x , 4, . , . .

, 4 ( x= ) , , x .

.