13 مارس لمجموعة عمل RIPE لمكافحة إساءة الاستخدام اعتبر اختطاف BGP (hjjack) بمثابة انتهاك لسياسة RIPE. إذا تم قبول الاقتراح، فإن مزود الإنترنت الذي تعرض للهجوم عن طريق اعتراض حركة المرور سيكون لديه الفرصة لإرسال طلب خاص لكشف المهاجم. إذا قام فريق المراجعة بجمع أدلة داعمة كافية، فسيتم اعتبار LIR الذي كان مصدر اعتراض BGP دخيلًا ويمكن تجريده من حالة LIR الخاصة به. وكانت هناك أيضا بعض الحجج تغيير.
في هذا المنشور، نريد أن نعرض مثالاً لهجوم لم يكن موضع التساؤل هو المهاجم الحقيقي فحسب، بل كان أيضًا موضع تساؤل القائمة الكاملة للبادئات المتأثرة. علاوة على ذلك، فإن مثل هذا الهجوم يثير مرة أخرى تساؤلات حول دوافع الاعتراضات المستقبلية لهذا النوع من حركة المرور.
على مدى العامين الماضيين، تم تغطية صراعات مثل MOAS (النظام المستقل متعدد الأصل) فقط في الصحافة باعتبارها اعتراضات BGP. تعد MOAS حالة خاصة حيث يعلن نظامان مستقلان مختلفان عن بادئات متعارضة مع أرقام ASN المقابلة في AS_PATH (أول ASN في AS_PATH، والمشار إليه فيما يلي باسم ASN الأصلي). ومع ذلك، يمكننا تسمية على الأقل اعتراض حركة المرور، مما يسمح للمهاجم بالتلاعب بسمة AS_PATH لأغراض مختلفة، بما في ذلك تجاوز الأساليب الحديثة للتصفية والمراقبة. نوع الهجوم المعروف - النوع الأخير من هذا الاعتراض ولكن ليس له أهمية على الإطلاق. ومن المحتمل أن يكون هذا هو بالضبط نوع الهجوم الذي شهدناه خلال الأسابيع الماضية. مثل هذا الحدث له طبيعة مفهومة وعواقب خطيرة للغاية.
يمكن لأولئك الذين يبحثون عن إصدار TL;DR التمرير إلى العنوان الفرعي "Perfect Attack".
خلفية الشبكة
(لمساعدتك على فهم العمليات التي تنطوي عليها هذه الحادثة بشكل أفضل)
إذا كنت تريد إرسال حزمة وكان لديك بادئات متعددة في جدول التوجيه تحتوي على عنوان IP الوجهة، فسوف تستخدم المسار للبادئة ذات الطول الأطول. إذا كان هناك عدة مسارات مختلفة لنفس البادئة في جدول التوجيه، فسوف تختار أفضلها (وفقًا لآلية اختيار المسار الأفضل).
تحاول أساليب التصفية والمراقبة الحالية تحليل المسارات واتخاذ القرارات من خلال تحليل السمة AS_PATH. قد يقوم جهاز التوجيه بتغيير هذه السمة إلى أي قيمة أثناء الإعلان. قد يكون مجرد إضافة ASN الخاص بالمالك في بداية AS_PATH (باعتباره ASN الأصلي) كافيًا لتجاوز آليات التحقق من الأصل الحالية. علاوة على ذلك، إذا كان هناك طريق من ASN المهاجم إليك، يصبح من الممكن استخراج واستخدام AS_PATH لهذا المسار في إعلاناتك الأخرى. سيتم في النهاية اجتياز أي عملية تحقق من صحة AS_PATH فقط لإعلاناتك المعدة.
لا تزال هناك بعض القيود الجديرة بالذكر. أولاً، في حالة تصفية البادئة من قبل موفر المنبع، قد يستمر ترشيح مسارك (حتى مع AS_PATH الصحيح) إذا كانت البادئة لا تنتمي إلى مخروط العميل الخاص بك الذي تم تكوينه في المنبع. ثانيًا، يمكن أن يصبح AS_PATH الصالح غير صالح إذا تم الإعلان عن المسار الذي تم إنشاؤه في اتجاهات غير صحيحة، وبالتالي ينتهك سياسة التوجيه. وأخيرًا، قد يعتبر أي مسار ببادئة تنتهك طول ROA غير صالح.
حادث
قبل بضعة أسابيع تلقينا شكوى من أحد مستخدمينا. لقد رأينا مسارات ببادئات ASN و/25 الأصلية الخاصة به، بينما ادعى المستخدم أنه لم يعلن عنها.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
أمثلة على الإعلانات لبداية شهر أبريل 2019
NTT في مسار البادئة /25 يجعلها مشبوهة بشكل خاص. ولم تكن شركة LG NTT على علم بهذا المسار وقت وقوع الحادث. لذا، نعم، يقوم بعض المشغلين بإنشاء AS_PATH بالكامل لهذه البادئات! يكشف فحص أجهزة التوجيه الأخرى عن رقم ASN واحد محدد: AS263444. وبعد النظر إلى طرق أخرى مع هذا النظام الذاتي، واجهنا الموقف التالي:
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
حاول تخمين ما هو الخطأ هنا
يبدو أن شخصًا ما أخذ البادئة من المسار، وقسمها إلى جزأين، وأعلن عن المسار بنفس AS_PATH لهاتين البادئتين.
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
أمثلة على المسارات لأحد أزواج البادئات المنقسمة
عدة أسئلة تثار في وقت واحد. هل قام أحد بالفعل بتجربة هذا النوع من الاعتراض عمليًا؟ هل سلك أحد هذه الطرق؟ ما هي البادئات التي تأثرت؟
وهنا تبدأ سلسلة إخفاقاتنا، وتبدأ جولة أخرى من خيبة الأمل إزاء الوضع الحالي لسلامة الإنترنت.
طريق الفشل
اهم الاشياء اولا. كيف يمكننا تحديد أجهزة التوجيه التي قبلت مثل هذه المسارات التي تم اعتراضها والتي يمكن إعادة توجيه حركة مرورها اليوم؟ لقد اعتقدنا أننا سنبدأ بالبادئات/25 لأنها "ببساطة لا يمكن أن يكون لها توزيع عالمي." كما يمكنك أن تتخيل، كنا مخطئين للغاية. تبين أن هذا المقياس صاخب للغاية ويمكن أن تظهر المسارات التي تحتوي على مثل هذه البادئات حتى من مشغلي المستوى الأول. على سبيل المثال، لدى NTT حوالي 1 بادئة من هذا القبيل، والتي توزعها على عملائها. من ناحية أخرى، هذا المقياس سيئ لأنه يمكن تصفية مثل هذه البادئات إذا استخدمها عامل التشغيل ، في جميع الاتجاهات. ولذلك، فإن هذه الطريقة غير مناسبة للعثور على جميع المشغلين الذين تم إعادة توجيه حركة المرور الخاصة بهم نتيجة لمثل هذا الحادث.
فكرة جيدة أخرى كنا نظن أن ننظر إليها . خاصة بالنسبة للمسارات التي تنتهك قاعدة maxLength الخاصة بالعائد على الوصول (ROA) المقابل. بهذه الطريقة يمكننا العثور على عدد أرقام ASN الأصلية المختلفة ذات الحالة "غير صالحة" والتي كانت مرئية لـ AS معين. ومع ذلك، هناك مشكلة "صغيرة". يبلغ متوسط (الوسيط والوضع) لهذا الرقم (عدد أرقام ASN الأصلية المختلفة) حوالي 150، وحتى لو قمنا بتصفية البادئات الصغيرة، فإنه يظل أعلى من 70. هذا الوضع له تفسير بسيط للغاية: لا يوجد سوى عدد قليل من المشغلين الذين يستخدمون بالفعل مرشحات ROA مع سياسة "إعادة تعيين المسارات غير الصالحة" عند نقاط الدخول، بحيث يظهر مسار به انتهاك ROA في العالم الحقيقي، ويمكن أن ينتشر في جميع الاتجاهات.
تسمح لنا الطريقتان الأخيرتان بالعثور على المشغلين الذين شاهدوا حادثتنا (نظرًا لأنها كانت كبيرة جدًا)، لكن بشكل عام لا يمكن تطبيقهما. حسنًا، لكن هل يمكننا العثور على الدخيل؟ ما هي السمات العامة لمعالجة AS_PATH؟ هناك بعض الافتراضات الأساسية:
- لم يتم رؤية البادئة في أي مكان من قبل؛
- أصل ASN (تذكير: أول ASN في AS_PATH) صالح؛
- آخر ASN في AS_PATH هو ASN الخاص بالمهاجم (في حالة قيام جاره بالتحقق من ASN الخاص بالجار على جميع المسارات الواردة)؛
- ينشأ الهجوم من مزود واحد.
إذا كانت جميع الافتراضات صحيحة، فستقدم جميع المسارات غير الصحيحة رقم ASN الخاص بالمهاجم (باستثناء رقم ASN الأصلي)، وبالتالي فهذه نقطة "حرجة". ومن بين الخاطفين الحقيقيين كان AS263444، على الرغم من وجود آخرين. حتى عندما تجاهلنا طرق الحادثة من الاعتبار. لماذا؟ قد تظل النقطة الحرجة حرجة حتى بالنسبة للطرق الصحيحة. يمكن أن يكون ذلك نتيجة لضعف الاتصال في منطقة ما أو القيود المفروضة على رؤيتنا.
ونتيجة لذلك، هناك طريقة لاكتشاف المهاجم، ولكن فقط في حالة استيفاء جميع الشروط المذكورة أعلاه وفقط عندما يكون الاعتراض كبيرًا بما يكفي لتجاوز حدود المراقبة. وإذا لم تتوفر بعض هذه العوامل، فهل يمكننا التعرف على البادئات التي عانت من هذا الاعتراض؟ لبعض المشغلين - نعم.
عندما يقوم أحد المهاجمين بإنشاء مسار أكثر تحديدًا، لا يتم الإعلان عن هذه البادئة بواسطة المالك الحقيقي. إذا كان لديك قائمة ديناميكية بجميع البادئات الخاصة بها، يصبح من الممكن إجراء مقارنة والعثور على طرق مشوهة أكثر تحديدًا. نقوم بجمع قائمة البادئات هذه باستخدام جلسات BGP الخاصة بنا، لأننا لا نحصل فقط على القائمة الكاملة للطرق المرئية للمشغل في الوقت الحالي، ولكن أيضًا قائمة بجميع البادئات التي يريد الإعلان عنها للعالم. لسوء الحظ، يوجد الآن العشرات من مستخدمي الرادار الذين لم يكملوا الجزء الأخير بشكل صحيح. سنقوم بإخطارهم قريبًا ونحاول حل هذه المشكلة. يمكن لأي شخص آخر الانضمام إلى نظام المراقبة لدينا الآن.
إذا عدنا إلى الحادث الأصلي، فقد اكتشفنا كل من المهاجم ومنطقة التوزيع من خلال البحث عن النقاط الحرجة. والمثير للدهشة أن AS263444 لم يرسل مسارات ملفقة إلى جميع عملائه. على الرغم من أن هناك لحظة غريبة.
BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
مثال حديث لمحاولة اعتراض مساحة العنوان الخاصة بنا
عندما تم إنشاء بادئات أكثر تحديدًا، تم استخدام AS_PATH الذي تم إنشاؤه خصيصًا. ومع ذلك، لا يمكن أخذ AS_PATH هذا من أي من مساراتنا السابقة. ليس لدينا حتى اتصال مع AS6762. وبالنظر إلى الطرق الأخرى في الحادثة، فإن بعضها كان لديه AS_PATH حقيقي تم استخدامه سابقًا، والبعض الآخر لم يكن لديه، حتى لو كان يبدو مثل الحقيقي. بالإضافة إلى ذلك، فإن تغيير AS_PATH ليس له أي معنى عملي، حيث سيتم إعادة توجيه حركة المرور إلى المهاجم على أي حال، ولكن يمكن تصفية المسارات ذات AS_PATH "السيئة" بواسطة ASPA أو أي آلية فحص أخرى. هنا نفكر في دوافع الخاطف. ليس لدينا حاليًا معلومات كافية لتأكيد أن هذا الحادث كان هجومًا مخططًا له. ومع ذلك، فمن الممكن. دعونا نحاول أن نتخيل موقفًا ما، على الرغم من أنه لا يزال افتراضيًا، ولكن من المحتمل أن يكون حقيقيًا تمامًا.
هجوم مثالي
ما لدينا؟ لنفترض أنك مزود طرق بث لخدمات النقل لعملائك. إذا كان لدى عملائك تواجد متعدد (منازل متعددة)، فلن تتلقى سوى جزء من حركة المرور الخاصة بهم. ولكن كلما زاد عدد الزيارات، زاد دخلك. لذا، إذا بدأت الإعلان عن بادئات الشبكة الفرعية لهذه المسارات نفسها بنفس AS_PATH، فستتلقى بقية حركة المرور الخاصة بها. ونتيجة لذلك، بقية الأموال.
هل سيساعد ROA هنا؟ ربما نعم، إذا قررت التوقف عن استخدامه تماما . بالإضافة إلى ذلك، من غير المرغوب فيه إلى حد كبير أن يكون لديك سجلات ROA ذات بادئات متقاطعة. بالنسبة لبعض المشغلين، مثل هذه القيود غير مقبولة.
بالنظر إلى آليات أمان التوجيه الأخرى، لن يساعد ASPA في هذه الحالة أيضًا (لأنه يستخدم AS_PATH من مسار صالح). لا يزال BGPSec ليس الخيار الأمثل نظرًا لانخفاض معدلات الاعتماد والاحتمال المتبقي لهجمات الرجوع إلى إصدار أقدم.
لذلك لدينا مكسب واضح للمهاجم ونقص في الأمن. مزيج رائع!
ماذا علي ان افعل؟
الخطوة الواضحة والأكثر جذرية هي مراجعة سياسة التوجيه الحالية الخاصة بك. قم بتقسيم مساحة العنوان الخاصة بك إلى أصغر الأجزاء (بدون تداخلات) التي تريد الإعلان عنها. قم بتسجيل ROA لهم فقط، دون استخدام معلمة maxLength. في هذه الحالة، يمكن لـ POV الحالي الخاص بك أن ينقذك من مثل هذا الهجوم. ومع ذلك، مرة أخرى، يعتبر هذا النهج غير معقول بالنسبة لبعض المشغلين بسبب الاستخدام الحصري لطرق أكثر تحديدًا. سيتم وصف جميع المشكلات المتعلقة بالحالة الحالية لعائد الوصول (ROA) وكائنات المسار في إحدى المواد المستقبلية لدينا.
بالإضافة إلى ذلك، يمكنك محاولة مراقبة مثل هذه الاعتراضات. للقيام بذلك، نحتاج إلى معلومات موثوقة حول البادئات الخاصة بك. وبالتالي، إذا قمت بإنشاء جلسة BGP مع المُجمع الخاص بنا وقمت بتزويدنا بمعلومات حول ظهورك على الإنترنت، فيمكننا العثور على نطاق لحوادث أخرى. بالنسبة لأولئك الذين لم يتصلوا بعد بنظام المراقبة الخاص بنا، في البداية، ستكون قائمة الطرق التي تحتوي على البادئات الخاصة بك كافية. إذا كانت لديك جلسة معنا، فيرجى التأكد من إرسال جميع مساراتك. ولسوء الحظ، فإن هذا الأمر يستحق التذكر لأن بعض عوامل التشغيل تنسى بادئة أو اثنتين، وبالتالي تتداخل مع طرق البحث لدينا. إذا تم ذلك بشكل صحيح، فسيكون لدينا بيانات موثوقة حول البادئات الخاصة بك، والتي ستساعدنا في المستقبل على تحديد واكتشاف هذا النوع (وغيره) من أنواع اعتراض حركة المرور تلقائيًا لمساحة عنوانك.
إذا علمت بمثل هذا الاعتراض لحركة المرور الخاصة بك في الوقت الفعلي، فيمكنك محاولة مواجهته بنفسك. الطريقة الأولى هي الإعلان عن المسارات باستخدام هذه البادئات الأكثر تحديدًا بنفسك. في حالة حدوث هجوم جديد على هذه البادئات، كرر.
النهج الثاني هو معاقبة المهاجم وأولئك الذين يعتبرون نقطة حرجة (للطرق الجيدة) عن طريق قطع وصول طرقك إلى المهاجم. يمكن القيام بذلك عن طريق إضافة ASN الخاص بالمهاجم إلى AS_PATH لمساراتك القديمة وبالتالي إجبارهم على تجنب ذلك AS باستخدام آلية الكشف عن الحلقة المضمنة في BGP .
المصدر: www.habr.com