हमलावर के AS-SET में पीड़ित को जोड़कर बीजीपी अपहरण

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

सरल बीजीपी अपहरण

संक्षेप में, बीजीपी अपहरण किसी और के आईपी पते (यादृच्छिक या जानबूझकर) पर कब्जा कर रहा है।

आमतौर पर, बीजीपी अपहर्ता इस तरह दिखता है: एक एएस जो एक उपसर्ग नहीं रखता है वह इसे (किसी और के उपसर्ग) की घोषणा करना शुरू कर देता है, अपलिंक / सहकर्मी इसे स्वीकार करते हैं, और यह इंटरनेट पर फैलने लगता है। वे इसे इस कारण से स्वीकार करते हैं कि जंक्शन पर उपसर्गों का कोई फ़िल्टरिंग नहीं है (या तो यह एक कॉन्फ़िगरेशन त्रुटि है, या इसलिए कल्पना की गई है (क्योंकि विभिन्न कारणों से बहुत बड़े ऑपरेटरों के साथ जंक्शन पर एक उपसर्ग फिल्टर का निर्माण करना बहुत मुश्किल है, यह इस लेख के लिए महत्वपूर्ण नहीं है) )। हाल के समय के सबसे हाई-प्रोफाइल उदाहरणों में से एक जब रोस्टेलकॉम ( एएस 12389 ) ने उपसर्ग मास्टरकार्ड ( एएस 26380 ), वीजा और कुछ अन्य वित्तीय संगठनों ( आधिकारिक संस्करण के अनुसार, सॉफ्टवेयर विफलता के परिणामस्वरूप) की घोषणा करना शुरू किया । आप देख सकते हैं कि इन घोषणाओं को bgplay इतिहास ( वेब , json ( संग्रह ) के माध्यम से देखने ) में कैसे देखा गया था, उनमें से एक आरआईपीई कलेक्टरों में से एक है (उपसर्ग 216.119.216.0/24 मास्टरकार्ड (AS26380) से संबंधित है):

"source_id": "05-193.203.0.185", "path": [ 6939, 12389 ], "community": [], "target_prefix": 216.119.216.0/24 

और यहाँ वही है जो वास्तविक घोषणा की तरह दिखता है:

  "source_id": "05-193.203.0.63", "path": [ 6720, 8447, 32787, 26380, 26380, 26380 ], "community": [ "1120:1" ], "target_prefix": 216.119.216.0/24 

यानी इस मामले में, रोस्टेलकॉम ने अपने AS से सीधे उपसर्ग की घोषणा की (AS-PATH में अंतिम AS 12389 है)। यदि रोस्टेलकॉम के अपलिंक और दावतों को रोस्टेलकॉम से उपसर्गों की सूची के अनुसार AS-SET और / या ROA RPKI के अनुसार उपसर्गों को सत्यापित करने से समस्याओं से बचा जा सकता है। बड़े ऑपरेटरों के बीच उपसर्ग सूचियों का निर्माण अक्सर नहीं किया जाता है, और सभी ने RPKI को लागू नहीं किया है (लेकिन प्रगति है )। ऐसा अपहरण, सैद्धांतिक रूप से, किसी के द्वारा भी किया जा सकता है, लेकिन केवल तभी घोषित किया जाता है जब कम से कम एक अपलिंक / दावत के माध्यम से "लीक" की घोषणा की जाती है। आमतौर पर, बड़े रूसी ऑपरेटर अपने ग्राहकों के लिए उपसर्ग फिल्टर को कॉन्फ़िगर करते हैं और इसलिए, छोटे एएस (छोटे / मध्यम आकार के ऑपरेटर, कुछ होस्टिंग और कुछ उद्यम), लगभग हमेशा, ऐसा हमला नहीं कर सकता है (लेकिन फिर से, यह सभी क्षेत्र पर निर्भर करता है / देश / विशिष्ट ऑपरेटर)।

हालाँकि, हमलावरों को अभी भी ऐसे स्थान (अपलिंक) मिलते हैं, जहाँ फ़िल्टरिंग कॉन्फ़िगर नहीं की गई है (2017 में, ब्राजील अपहरण में अग्रणी था) और IP पते को हथियाने के लिए एक हमले को अंजाम दिया (अक्सर, ऐसी घटनाएं समाचार फ़ीड में आती हैं), एक अधिक प्रभावी हमले के लिए, एक वास्तविक प्रवर्तक की तुलना में अधिक विशिष्ट उपसर्गों (एक लंबे मुखौटा के साथ) की घोषणा करें। अब हम आक्रमण संस्करण पर चलते हैं, जहाँ न तो ROA RPKI सत्यापन और न ही AS-SET उपसर्ग सूचियाँ बचती हैं।

अपने एएस-एसईटी में एएस पीड़ित के अतिरिक्त के साथ बीजीपी अपहरण

इस परिदृश्य पर विचार करें:

1. एक हमलावर एएस और आईपी पते प्राप्त करता है (वास्तव में, तकनीकी रूप से, उसे आईपी पते की आवश्यकता नहीं है, वे सिर्फ सवाल नहीं करने की संभावना है)।
2. हमलावर विभिन्न बड़े ऑपरेटरों और IX (कम से कम एक ऑपरेटर या IX) से जुड़ता है, न केवल उसकी AS को निर्दिष्ट करता है, बल्कि उसके AS-SET को घोषित उपसर्गों के बारे में डेटा के स्रोत के रूप में (यह अंतर-ऑपरेटर इंटरैक्शन के लिए सामान्य अभ्यास है) जब एक ग्राहक-अपलिंक संबंध में) या IX- आह पर शामिल किए जाने के लिए))। सामान्य मामले में, एएस-एसईटी निर्दिष्ट है, और न केवल एएस, जब यह माना जाता है कि ग्राहक एक मृत अंत नहीं है, लेकिन यह स्वयं के पास है (या होगा) बीजीपी और अपने स्वयं के नेटवर्क के साथ ग्राहक।
3. कुछ समय बाद, हमलावर पीड़ित के एएस को अपने एएस-एसईटी में जोड़ता है और खुद के माध्यम से अपने उपसर्ग की घोषणा करना शुरू कर देता है, अर्थात। घोषित AS-PATH इस तरह दिखता है: "AS_ हमलावर AS_ पीड़ित"। स्वचालित रूप से निर्मित उपसर्ग सूचियों के दृष्टिकोण से और RPKI के दृष्टिकोण से, यह पूरी तरह से वैध घोषणा है, इसलिए दोनों सुरक्षा तंत्र यहां काम नहीं करेंगे।
4. घोषित उपसर्ग वास्तविक घोषणा (पीड़ित की घोषणा) के साथ प्रतिस्पर्धा करना शुरू कर देता है, कहीं वह जीत जाता है और रूटिंग टेबल में हो जाता है, कहीं वह हार जाता है और जीत नहीं पाता है (पीड़ित की घोषणा वहीं रहेगी)। यह निर्भर करता है कि कितने अपलिंक और कितने IX एक हमलावर का उपयोग करते हैं। जब कोई हमलावर कुछ AS को क्लाइंट के रूप में जोड़ता है, तो उसके अंदर (सबसे अधिक बार) वह एक बड़े लोकल-प्रीफ़ के कारण पीड़ित को जीत लेगा (यदि पीड़ित एक ही अपलिंक का क्लाइंट नहीं है, तो पीड़ित AS-PATI द्वारा जीत जाएगा यदि वह नहीं करता है prepend), अर्थात एक हमलावर को अपने हमले की प्रभावशीलता को अधिकतम करने के लिए अपने AS-SET के साथ अधिक से अधिक अपलिंक से कनेक्ट करने की आवश्यकता है।
   इसके अलावा, हमलावर को IX की अधिकतम संख्या से कनेक्ट होना चाहिए, जैसा कि आमतौर पर, डेडलॉक ASS, IXs में सबसे अधिक स्थानीय-प्रीफ़ सेट करते हैं और यदि पीड़ित उपसर्ग IX में शामिल नहीं होता है, तो यह डेडलॉक ASs के रूटिंग टेबल में हमलावर की घोषणा को खो देगा।

सिद्धांत रूप में, यह एक बहुत मजबूत हमला है, लेकिन सौभाग्य से, व्यवहार में, निम्नलिखित सीमाएं उत्पन्न होंगी:

1. आपको कम से कम एक कानूनी इकाई तैयार करने की आवश्यकता है, लेकिन वास्तव में, विभिन्न देशों में सबसे अधिक संभावना होगी।
2. ऑपरेटरों, IXs के साथ समझौतों का समापन करना आवश्यक है, लगभग हमेशा एक कनेक्शन शुल्क बनाते हैं, LIR / RIR के साथ।
3. कुछ ऑपरेटर अभी भी स्वचालित रूप से AS-SET उपसर्ग सूचियों का निर्माण नहीं करते हैं, उन्हें इसके लिए पत्र लिखने की आवश्यकता होती है। किसी अनुभवी कंपनी का AS-ka अचानक किसी अनजान कंपनी के AS-SET में दिखाई देने पर एक अनुभवी व्यवस्थापक को कुछ संदेह होगा।
4. हमले के बाद, उपयोग किए जाने वाले उपकरण (यदि यह किसी प्रकार के डेटा सेंटर में स्थित है) सबसे अधिक संभावना है कि इस घटना में जब्त किया जाएगा कि एक आपराधिक मामला खोला गया है।
5. विभिन्न ऑपरेटरों / IX के लिए उपसर्ग सूचियाँ अलग-अलग समय पर अपडेट की जाती हैं, इसलिए आपको विश्लेषण करना होगा कि कौन अपडेट करता है जब यह सबसे आसान काम भी नहीं है।

संभावित सुरक्षा उपाय:

1. सैद्धांतिक रूप से, इस तरह के हमले से बचाव के लिए, आपको ऑपरेटरों (बेहतर, ग्राहक वाले) के साथ अधिक से अधिक इंटरफेस रखने की आवश्यकता है, क्योंकि उनके पास स्थानीय-पूर्व उच्चतर है) और IXs। यानी वही करें जो एक हमलावर करेगा। बेशक, व्यवहार में यह लागू करना बेहद मुश्किल है और इसके लिए महत्वपूर्ण संसाधनों की आवश्यकता होगी। यह विधि केवल उन सेवाओं के लिए प्रासंगिक है जो पेशेवर आधार पर सूचना सुरक्षा सेवाएं प्रदान करती हैं।
2. यदि आपके पास कोई वेबसाइट है, तो खाता कार्य के साथ CAA रिकॉर्ड का उपयोग करें (यदि आपका SSL प्रमाणपत्र प्रदाता इसका समर्थन करता है। Letsencrypt समर्थन करता है) ( RFC6844 देखें)। इस मामले में, हमलावर एक प्रमाण पत्र जारी करने में सक्षम नहीं होगा (जब तक कि वह सीएए रिकॉर्ड को बदल नहीं सकता)
3. सैद्धांतिक रूप से, बीजीपीएससी के व्यापक कार्यान्वयन को इस तरह के हमले को खत्म करना चाहिए, लेकिन इसका भाग्य अभी तक स्पष्ट नहीं है (व्यवहार में यह अभी तक लागू नहीं हुआ है या बहुत कम ही होता है)।
4. वैकल्पिक सत्यापन का कार्यान्वयन AS_PATH (बिना BGPsec) (अब तक यह एक मसौदा है जो इसके व्यापक कार्यान्वयन के मामले में वर्णित समस्या को हल करता है)।
5. आपके AS-SET (AS स्वामी की अनुमति के बिना) के लिए एक विदेशी AS के अनियंत्रित जोड़ का निषेध उन क्षेत्रों में ऐसे हमले करने की संभावना को कम कर सकता है जहां AS-SET का उपयोग जंक्शनों पर फ़िल्टर करने के लिए किया जाता है। अब ऐसी कोई पाबंदी नहीं है।

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

क्या torproject.org पर कब्जा करना मुश्किल है

एक हमलावर को दो समस्याओं को हल करने की आवश्यकता है:

• लक्षित दर्शकों (लक्षित दर्शकों - जो नकली साइट प्राप्त करेंगे) पर पुनर्निर्देशित ट्रैफ़िक
• प्रमाण पत्र तैयार करें

परिचयात्मक:

 $ dig torproject.org CAA +short 128 issuewild "\;" 0 iodef "mailto:torproject-admin@torproject.org" 128 issue "globalsign.com" 128 issue "letsencrypt.org" $ dig torproject.org +short 95.216.163.36 138.201.14.197 

जैसा कि आप देख सकते हैं, एक CAA रिकॉर्ड है, आप Letencrypt से एक प्रमाण पत्र प्राप्त कर सकते हैं, CAA रिकॉर्ड में खाते के लिए कोई बाध्यकारी नहीं है, जिसका अर्थ है कि समस्या सैद्धांतिक रूप से हमलावर द्वारा हल की गई है। Torproject.org के आईपी पते प्रसिद्ध हेज़नर होस्टिंग के स्वामित्व में हैं।

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

Letencrypt में एक प्रमाण पत्र प्राप्त करने के लिए, आपको प्रदाता की आवश्यकता होती है, जिस पर Letencrypt हमलावर को सीधे यातायात की मेजबानी कर रहा है, न कि हेज़नर (AS24940) को। Letencrypt अमेरिकी और यूरोपीय IP के लिए अलग-अलग पते पर स्थित है, लेकिन आइए देखें कि acme-v02.api.letsencrypt.org/2.19.125.202 से ट्रैफ़िक को प्रभावित करना कितना मुश्किल होगा, हमलावर के होस्ट पर जाएँ। यहां हमें इस तथ्य का सामना करना पड़ रहा है कि एक्सेन्क्रिप्ट को अकामाई सीडीएन पर होस्ट किया गया है, जिसकी दुनिया भर में बहुत अच्छी कनेक्टिविटी है (यह सबसे प्रमुख IXs पर मौजूद है, जिसमें बड़ी संख्या में बड़े खिलाड़ियों के साथ सीधे जोड़ हैं)। अकामाई के पास सार्वजनिक एलजी नहीं है, सिद्धांत रूप में, क्लाइंट के लिए एक एपीआई है जिसके साथ आप ट्रेसरआउट / पिंग कर सकते हैं, लेकिन यहां तक ​​कि एक सार्वजनिक एलजी के बिना, आप उनकी उपस्थिति के पैमाने का आकलन करने के लिए peering db पर एक नज़र डाल सकते हैं। इसी तरह, आप हेज़नर को देख सकते हैं। यह देखना आसान है कि दोनों AS में समान IX की मौजूदगी है, इसलिए हम यह निष्कर्ष निकाल सकते हैं कि एकता के करीब एक संभावना के साथ, Akamai तालिका में AS हेज़नर उपसर्ग (AS24940) AS_PATH 24940 के साथ दिखाई दे रहे हैं। इसका मतलब है कि अगर एक हमलावर यदि यह कुछ IX के माध्यम से हेज़नर के उपसर्गों की घोषणा करने की कोशिश करता है, तो वे AS_PATH के अनुसार खो देंगे, हेज़नर से वास्तविक घोषणाएं (क्योंकि AS_PATH में हमलावर का AS होगा)। एक संभावित समाधान हमलावर और अकामाई (यदि अकामाई इस बात से सहमत है और यदि IXs के साथ जंक्शनों की तुलना में अधिक है तो) के बीच एक "प्रत्यक्ष" आयोजन करना होगा।

संक्षेप में, अपने AS-SET में किसी और के AS को जोड़कर, आप torproject.org वेबसाइट (ग्राहकों की एक बड़ी संख्या के लिए, लेकिन सामान्य स्थिति में सभी के लिए नहीं) के महत्वपूर्ण गिरावट का कारण बन सकते हैं, लेकिन LetSecrypt में टोरप्रोजेक्ट एसएसएल प्रमाणपत्र प्राप्त करें, सबसे अधिक संभावना यह है कि यह वास्तविक प्रवर्तक (हेज़नर) और CDN के बीच अच्छे संपर्क के कारण काम करता है, जो कि Letencrypt (अकामाई) द्वारा उपयोग किया जाता है। हालांकि, अन्य मामलों में, जब पीड़ित साइट की मेजबानी और प्रमाणन प्राधिकरण के बीच पारगमन ASS होते हैं और वे AS_PATH में मौजूद होते हैं, तो वर्णित विधि का उपयोग करके प्रमाण पत्र प्राप्त करने का जोखिम काफी बढ़ जाता है।