كل شيء سيء للغاية أو نوع جديد من اعتراض حركة المرور

في 13 مارس ، تلقت مجموعة عمل RIPE لمكافحة إساءة المعاملة اقتراحًا للنظر في عملية الاختطاف باعتبارها انتهاكًا لسياسة RIPE. إذا تم قبول العرض ، فسيتمكّن موفر خدمة الإنترنت الذي تمت مهاجمته عن طريق اعتراض حركة المرور من إرسال طلب خاص لجلب المهاجم إلى المياه النظيفة. إذا قام فريق الخبراء بجمع ما يكفي من الأدلة الداعمة ، فإن مثل هذا LIR ، وهو مصدر اعتراض BGP ، سيعتبر دخيلًا ويمكن أن يُحرم من حالة LIR. كانت هناك بعض الحجج ضد هذا التغيير.

في هذا المنشور ، نريد عرض مثال للهجوم عندما لا يكون المهاجم الحقيقي فقط موضع شك ، ولكن القائمة الكاملة للبادئات المتأثرة. علاوة على ذلك ، يثير هذا الهجوم مرة أخرى تساؤلات حول دوافع اعتراضات مستقبلية لهذا النوع من الحركة.

على مدار العامين الماضيين ، تم الإبلاغ عن تعارضات فقط مثل MOAS (نظام الحكم الذاتي متعدد المنشأ) في الصحافة عند اعتراض BGP. MOAS هي حالة خاصة عندما يعلن نظامان مستقلان مختلفان عن بادئات متعارضة مع أرقام ASN المقابلة في AS_PATH (أول ASN في AS_PATH ، يشار إليها فيما يلي باسم ASN الأصلي). ومع ذلك ، يمكننا تسمية ما لا يقل عن 3 أنواع إضافية من اعتراض حركة المرور التي تسمح للمهاجم بمعالجة سمة AS_PATH لأغراض مختلفة ، بما في ذلك من أجل التحايل على الأساليب الحديثة في التصفية والمراقبة. النوع المعروف من هجوم Pilosov-Kapela هو آخر نوع من هذا الاعتراض ، ولكن ليس على الإطلاق في الأهمية. من المحتمل أن يكون هذا هو بالضبط الهجوم الذي لاحظناه خلال الأسابيع الماضية. مثل هذا الحدث له طبيعة مفهومة وعواقب وخيمة إلى حد ما.

يمكن لأولئك الذين يبحثون عن إصدار 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 ، لأنها "ببساطة لا يمكن أن يكون لها توزيع عالمي." كما يمكنك التخمين ، كنا مخطئين للغاية. كان هذا القياس صاخبًا جدًا ويمكن أن تظهر المسارات التي تحتوي على هذه البادئات حتى من مشغلي المستوى 1. على سبيل المثال ، لدى NTT حوالي 50 بادئة من هذا القبيل تقوم بتوزيعها بين عملائها. من ناحية أخرى ، يعد هذا القياس سيئًا لأنه يمكن تصفية هذه البادئات إذا طبق المشغل تصفية البادئات الصغيرة في جميع الاتجاهات. لذلك ، هذه الطريقة غير مناسبة للبحث عن جميع المشغلين الذين تمت إعادة توجيه حركة المرور الخاصة بهم نتيجة لهذا الحادث.

فكرة أخرى جيدة كنا نظن أن ننظر إلى بوف . لا سيما على الطرق التي تنتهك قاعدة maxLength من ROA المقابلة. وبالتالي ، يمكن أن نجد عدد ASNs الأصل مختلفة مع حالة غير صالحة التي كانت مرئية لهذا AS. ومع ذلك ، هناك مشكلة "صغيرة". يبلغ متوسط ​​القيمة (الوسيط والوضع) لهذا الرقم (عدد ASNs الأصل المختلف) حوالي 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 أو أي آلية تحقق أخرى. هنا فكرنا في دوافع الخاطف. الآن ليس لدينا بيانات كافية تدعي أن هذا الحادث كان هجومًا مخططًا له. ومع ذلك ، فمن الممكن. دعونا نحاول أن نتخيل وضعًا افتراضيًا ، لكن يحتمل أن يكون حقيقيًا.

هجوم مثالي

ماذا لدينا؟ لنفترض أنك مزود خدمة عبور يبث طرقًا لعملائك. إذا كان لدى عملائك وجود متعدد (multihome) ، فستتلقى جزءًا فقط من زياراتهم. ولكن كلما زاد عدد الزيارات - زاد دخلك. لذلك ، إذا بدأت في الإعلان عن بادئات الشبكة الفرعية لنفس المسارات بنفس AS_PATH ، فستتلقى بقية زياراتها. ونتيجة لذلك ، فإن بقية المال.

هل ستساعد ROA هنا؟ ربما نعم ، إذا قررت التخلي تمامًا عن استخدام maxLength . بالإضافة إلى ذلك ، من غير المرغوب فيه للغاية وجود إدخالات ROA مع بادئات متقاطعة. بالنسبة لبعض المشغلين ، هذه القيود غير مقبولة.

مع مراعاة آليات أمان التوجيه الأخرى ، لن تساعد ASPA في هذه الحالة أيضًا (لأن AS_PATH يُستخدم من مسار صالح). BGPSec لا يزال ليس الخيار الأفضل بسبب انخفاض معدل القبول والإمكانية المتبقية لهجمات خفض التصنيف.

وبالتالي ، لدينا ربح واضح للمهاجم وانعدام الأمن. مزيج رائع!

ما الذي يجب علي فعله؟

الخطوة الواضحة والأكثر تطرفًا هي مراجعة سياسة التوجيه الحالية. قسّم مساحة عنوانك إلى أصغر الأجزاء (بدون التقاطعات) التي تريد فقط الإعلان عنها. قم بالتوقيع على ROAs لهم فقط ، وليس باستخدام المعلمة maxLength. في هذه الحالة ، يمكن أن يوفر لك POV الحالي من مثل هذا الهجوم. ومع ذلك ، مرة أخرى ، فإن هذا النهج غير مناسب لبعض المشغلين بسبب الاستخدام الحصري لطرق أكثر تحديدًا. سيتم وصف جميع مشكلات الحالة الحالية لعائد ROA وكائنات المسار في إحدى موادنا المستقبلية.

بالإضافة إلى ذلك ، يمكنك محاولة مراقبة مثل هذه الاعتراضات. للقيام بذلك ، نحتاج إلى معلومات موثوقة حول البادئات الخاصة بك. وبالتالي ، إذا قمت بإنشاء جلسة BGP مع جامعنا وقمت بتزويدنا بمعلومات حول مدى رؤيتك للإنترنت ، فيمكننا إيجاد منطقة التوزيع للحوادث الأخرى أيضًا. بالنسبة لأولئك الذين لم يتصلوا بعد بنظام المراقبة الخاص بنا - بالنسبة للمبتدئين ، ستكون قائمة الطرق التي تحتوي على البادئات فقط كافية. إذا كانت لديك جلسة معنا ، فالرجاء التحقق من إرسال جميع مساراتك. لسوء الحظ ، يجدر التذكير ، لأن بعض المشغلين ينسى بادئة أو اثنتين ، وبالتالي يتداخلون مع أساليب البحث لدينا. إذا تم تنفيذ كل شيء بشكل صحيح ، فسنحصل على بيانات موثوقة حول البادئات ، مما سيساعد في المستقبل على اكتشاف واكتشاف مثل هذه الأنواع (وغيرها) الأخرى من اعتراض حركة المرور لمساحة عنوانك.

إذا اكتشفت في الوقت الفعلي مثل هذا الاعتراض لحركة المرور الخاصة بك ، يمكنك محاولة مواجهته بنفسك. تتمثل الطريقة الأولى في الإعلان عن المسارات باستخدام هذه البادئات الأكثر تحديدًا بنفسك. في حالة حدوث هجوم جديد على هذه البادئات - كرر.

الطريقة الثانية هي معاقبة المهاجم وأولئك الذين يمثلون نقطة حرجة (للطرق الجيدة) عن طريق قطع وصول طرقك عن المهاجم. يمكن القيام بذلك عن طريق إضافة ASN للمهاجم إلى AS_PATH من الطرق القديمة الخاصة بك ، وبالتالي جعلهم يتجنبون ذلك AS باستخدام آلية الكشف عن الحلقة المدمجة في BGP لمصلحتهم الخاصة .