Rostelecom मा BGP मार्गको चुहावटले सबैभन्दा ठूला नेटवर्कहरूको जडानमा अवरोध पुर्‍यायो

एक गलत BGP घोषणाको परिणाम स्वरूप, 8800 भन्दा बढी विदेशी नेटवर्क उपसर्गहरू माथि उठ्यो पुनर्निर्देशित Rostelecom नेटवर्क मार्फत, जसले मार्गको छोटो अवधिको पतन, नेटवर्क जडानमा अवरोध र विश्वभरका केही सेवाहरूमा पहुँचमा समस्याहरू निम्त्यायो। समस्या ढाकिएको Akamai, Cloudflare, Digital Ocean, Amazon AWS, Hetzner, Level200, Facebook, Alibaba र Linode सहित प्रमुख इन्टरनेट कम्पनीहरू र सामग्री वितरण नेटवर्कहरूको स्वामित्वमा रहेका २०० भन्दा बढी स्वायत्त प्रणालीहरू।

Rostelecom (AS12389) द्वारा अप्रिल 1 मा 22:28 (MSK) द्वारा गलत घोषणा गरिएको थियो, त्यसपछि यसलाई प्रदायक Rascom (AS20764) ले उठायो र चेनसँगै यो Cogent (AS174) र Level3 (AS3356) मा फैलियो। , जसको क्षेत्रले लगभग सबै इन्टरनेट प्रदायकहरूलाई पहिलो स्तरमा कभर गरेको छ (टियर-२). सेवाहरू मोनिटोरिन्गा BGP ले तुरुन्तै Rostelecom लाई समस्या बारे सूचित गर्यो, त्यसैले घटना लगभग 10 मिनेट सम्म चल्यो (का अनुसार अन्य डाटा प्रभाव लगभग एक घण्टाको लागि अवलोकन गरिएको थियो)।

Rostelecom को पक्षमा त्रुटि समावेश भएको यो पहिलो घटना होइन। 2017 मा Rostelecom मार्फत 5-7 मिनेट भित्र पुन: निर्देशित गरिएको थियो भिसा र मास्टरकार्ड सहित ठूला बैंकहरू र वित्तीय सेवाहरूको नेटवर्कहरू। दुवै घटनामा, समस्याको स्रोत देखिन्छ सेवा गरियो ट्राफिक व्यवस्थापनसँग सम्बन्धित काम, उदाहरणका लागि, केही सेवाहरू र CDN हरूका लागि आन्तरिक निगरानी, ​​प्राथमिकता वा ट्राफिकको मिररिङ व्यवस्थित गर्दा रुटको चुहावट हुन सक्छ। मार्च छलफल गरियो स्वदेशी स्रोतहरूको पक्षमा विदेशी सेवाहरूको यातायातको प्राथमिकता घटाउने मुद्दा)। उदाहरणका लागि, केही वर्षअघि पाकिस्तानमा एउटा प्रयास गरिएको थियो बेर्नु शून्य इन्टरफेसमा YouTube सबनेटहरूले BGP घोषणाहरूमा यी सबनेटहरूको उपस्थिति र सबै YouTube ट्राफिकको प्रवाहलाई पाकिस्तानमा पुर्‍यायो।

यो रोचक छ कि Rostelecom संग घटना अघि दिन, शहर देखि सानो प्रदायक "नयाँ वास्तविकता" (AS50048)। सुमेरल्या Transtelecom मार्फत थियो घोषणा गरे Orange, Akamai, Rostelecom र 2658 भन्दा बढी कम्पनीहरूको नेटवर्कलाई असर गर्ने 300 उपसर्गहरू। मार्ग चुहावटको कारण धेरै मिनेटसम्म ट्राफिक रिडिरेक्टको धेरै छालहरू थिए। यसको शिखरमा, समस्याले 13.5 मिलियन आईपी ठेगानाहरूलाई असर गर्यो। Transtelecom को प्रत्येक ग्राहकको लागि मार्ग प्रतिबन्धहरूको प्रयोगको लागि एक उल्लेखनीय विश्वव्यापी अवरोधलाई बेवास्ता गरियो।

यस्तै घटनाहरू इन्टरनेटमा हुन्छन् नियमित रूपमा र सबै ठाउँमा लागू नभएसम्म जारी रहनेछ प्राधिकरण विधिहरू BGP घोषणाहरू RPKI (BGP उत्पत्ति प्रमाणीकरण) मा आधारित छन्, नेटवर्क मालिकहरूबाट मात्र घोषणाहरूको स्वागत गर्न अनुमति दिँदै। प्राधिकरण बिना, कुनै पनि अपरेटरले मार्ग लम्बाइको बारेमा काल्पनिक जानकारीको साथ सबनेटको विज्ञापन गर्न सक्छ र विज्ञापन फिल्टरिङ लागू नगर्ने अन्य प्रणालीहरूबाट ट्राफिकको अंशको माध्यमबाट ट्रान्जिट सुरु गर्न सक्छ।

उही समयमा, विचाराधीन घटनामा, RIPE RPKI भण्डार प्रयोग गरेर चेक बाहिरियो। बेकार। संयोगले, Rostelecom मा BGP मार्ग चुहावट हुनु तीन घण्टा अघि, RIPE सफ्टवेयर अपडेट गर्ने प्रक्रियामा, संयोगवश मेटाइयो 4100 ROA रेकर्डहरू (RPKI रूट उत्पत्ति प्राधिकरण)। डाटाबेस अप्रिल 2 मा मात्र पुनर्स्थापित गरिएको थियो, र यो सबै समय RIPE क्लाइन्टहरूको लागि चेक अकार्यक्षम थियो (समस्याले अन्य रजिस्ट्रारहरूको RPKI भण्डारहरूलाई असर गर्दैन)। आज RIPE सँग 7 घण्टा भित्र नयाँ समस्याहरू र RPKI भण्डारहरू छन् अनुपलब्ध थियो.

रजिस्ट्री-आधारित फिल्टरिङ पनि लीक ब्लक गर्न एक समाधान रूपमा प्रयोग गर्न सकिन्छ IRR (इन्टरनेट राउटिंग रजिस्ट्री), जसले स्वायत्त प्रणालीहरू परिभाषित गर्दछ जसको माध्यमबाट निर्दिष्ट उपसर्गहरूको मार्गलाई अनुमति दिइन्छ। साना अपरेटरहरूसँग अन्तरक्रिया गर्दा, मानव त्रुटिहरूको प्रभाव कम गर्न, तपाईंले EBGP सत्रहरू (अधिकतम-उपसर्ग सेटिङ) को लागि स्वीकृत उपसर्गहरूको अधिकतम संख्या सीमित गर्न सक्नुहुन्छ।

अधिकांश अवस्थामा, घटनाहरू आकस्मिक कर्मचारी त्रुटिहरूको परिणाम हो, तर हालसालै त्यहाँ लक्षित आक्रमणहरू पनि भएका छन्, जसमा आक्रमणकारीहरूले प्रदायकहरूको पूर्वाधारमा सम्झौता गर्छन्। संगठित गर्ने पुनर्निर्देशन и अवरोध लागि यातायात प्रतिस्थापन DNS प्रतिक्रियाहरू प्रतिस्थापन गर्न MiTM आक्रमण व्यवस्थित गरेर विशिष्ट साइटहरू।
त्यस्ता आक्रमणहरूको समयमा TLS प्रमाणपत्रहरू प्राप्त गर्न अझ गाह्रो बनाउनको लागि, प्रमाणपत्र प्राधिकरणलाई एन्क्रिप्ट गर्नुहोस् भर्खरै स्विच गरियो विभिन्न सबनेटहरू प्रयोग गरेर बहु-स्थिति डोमेन जाँच गर्न। यस चेकलाई बाइपास गर्नको लागि, आक्रमणकर्ताले विभिन्न अपलिङ्कहरू सहित प्रदायकहरूको धेरै स्वायत्त प्रणालीहरूको लागि एकैसाथ मार्ग रिडायरेक्शन प्राप्त गर्न आवश्यक छ, जुन एकल मार्ग रिडिरेक्ट गर्नु भन्दा धेरै गाह्रो छ।

स्रोत: opennet.ru