الخلاصة

  • مجتمع BLACKHOLE في RFC 7999 طلب استشاري لإسقاط المرور المتجه إلى البادئة الموسومة، وليس أمراً ملزماً. لا ينفذه المستقبل إلا باتفاق مسبق على الجلسة، وإثبات حق الجار في بادئة تغطي الهدف، وسياسة محلية صريحة.
  • يزرع RTBH القائم على الوجهة مساراً أكثر تخصيصاً ينتهي إلى discard أو null. يخف ضغط الهجوم عن الوصلة، لكن المرور المشروع إلى العنوان نفسه يُحذف معه.
  • يجب أن يصل الإثبات بين UPDATE الخام، وتفويض البادئة، وموافقة الحادث، وROV، وسياسة الاستيراد، وحصر الانتشار، وRIB، وFIB، والعدادات، والحزم، والسحب، واستعادة الخدمة. بقاء الجلسة Established لا يثبت أياً من ذلك.

حماية الوصلة عبر التضحية بعنوان

لنفترض واقعة تركيبية. يتعرض عميل نقل لهجوم حجمي على 203.0.113.19. تمتلئ وصلة الوصول قبل أن يفيد مرشح لدى العميل. يعلن العميل 203.0.113.19/32 لمزوده مع BLACKHOLE. الخدمة مفعّلة مسبقاً على تلك الجلسة، والمزود يعرف أن العميل مخول بإعلان 203.0.113.0/24.

يقبل المزود /32، ويقيده داخل شبكته، ويجعله يحل إلى فعل إسقاط عند منافذ الدخول. لا يعبر الهجوم الوصلة المحدودة بعد الآن، ولا تعبر الاتصالات المشروعة إلى المضيف. تبقى بقية عناوين /24 قابلة للوصول. لم تُنقذ الضحية؛ بل جرى فصلها لحماية السعة والخدمات المحيطة.

بعد ساعات، تختار الأتمتة 203.0.113.91/32 بالخطأ، وهو عنوان خدمة سليمة ضمن المجموعة نفسها. النظير صحيح، والتغطية صحيحة، والمجتمع صحيح. إذا كانت هذه كل الضوابط، ينفذ المزود طلباً سليم البنية ذا نية حادث خاطئة. لا تسقط الجلسة ولا تختفي البادئة الكلية، لكن الخدمة الثانية تصمت.

المثال ليس ادعاءً عن انقطاع عام. وظيفته إظهار الحد: امتلاك حق الإعلان داخل كتلة لا يثبت أن شخصاً مخولاً قصد الآن التضحية بهذا المضيف بعينه.

معنى مشترك لا يخلق أمراً عالمياً

تسجل IANA قيمة BLACKHOLE بوصفها 0xFFFF029A، وتظهر عادةً 65535:666. تصفها RFC 7999 بأنها مجتمع BGP معروف، انتقالي واستشاري للحجب الأسود القائم على الوجهة. القيمة الموحدة تقلل تعدد رموز المشغلين وأخطاء التفعيل.

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

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

هذه قسمة عملية لمبدأ Heng Lu في الحد الأدنى للمواصفة الأولية. الطبقة المشتركة ضيقة: قيمة مستقرة ومعنى طلب الإسقاط. أما الأهلية والتسعير والمنطقة والأجهزة والمدة فتبقى محلية. القرار المستقبلي المحلي يسمح بالتبني أو الرفض من دون أن تجعل جهة مركزية عدم التبني حالة بطلان. والتبني الطوعي يعني أن الوثيقة والسجل لا يسقطان حزمة؛ التنفيذ والاعتماد في الأنظمة العاملة يفعلان ذلك.

أفضل مسار قد يعني عدم التسليم

تصف RFC 5635 مساراً ينتهي إلى واجهة null أو discard. تجعل سياسة BGP البادئة الأكثر تخصيصاً تحل إلى ذلك المسار، فتُسقط الحزم قرب منافذ الدخول قبل أن تستهلك السعة حتى العميل.

لذلك قد يكون المسار صحيحاً، ويفوز بالاختيار، ويظهر في Loc-RIB، فيما تكون نتيجة التحويل المقصودة هي عدم التسليم. وجوده في RIB لا يثبت قابلية الوصول المعتادة، ولا يثبت الإسقاط أيضاً من دون فحص FIB وحل next hop في كل فئة دخول.

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

عبارة «تم التخفيف» لا تكفي. يجب أن تحدد الإدارة ما الذي جرى حمايته، ومن تحمل ثمن الحماية.

قفلان في RFC وقفل ثالث خارج BGP

تشترط RFC 7999 في العلاقة الثنائية أن تكون بادئة blackhole مغطاة ببادئة مساوية أو أقصر يحق للجار إعلانها. وتشترط أيضاً أن يكون المستقبل قد وافق على تطبيق BLACKHOLE في تلك الجلسة تحديداً.

يمنع القيد الأول العميل من إسقاط وجهات لا تخصه. ويمنع الثاني تحول أي peering إلى قناة فصل. إنهما يحددان المساحة والعلاقة.

لكنهما لا يثبتان نية الحادث كاملةً. قد يقع /32 الخاطئ داخل /24 الصحيح. وقد تُخترق بيانات الاعتماد أو يعاد طلب قديم بعد انتهاء الهجوم. لا يحمل UPDATE سجلاً عالمياً يبين من وافق، وأي خدمة ستتوقف، ولماذا، وحتى متى، ومن يسحب الطلب.

يجب أن يوفر النظام التشغيلي القفل الثالث: هوية الطالب، ومعرف الحادث، والبادئة الدقيقة، والخدمة، والسبب، والنطاق، ووقت الموافقة، والانتهاء، ومسؤول السحب. ويرتبط ذلك بالنظير وAFI/SAFI وإصدار السياسة الذي عالج المسار.

يجيب مرشح البادئة: هل يجوز لهذا العميل الإعلان ضمن هذه المساحة؟ ويجيب سجل الحادث: هل أراد مخول فعلاً إسقاط هذه الوجهة الآن؟ موافقة بشرية بلا مرشح حتمي معرضة للخطأ؛ ومرشح بلا نية يمنح الأتمتة امتياز فصل دائم لكل الكتلة.

دقة host route تحتاج استثناءً مضبوطاً

توصي RFC 7999 بأكثر بادئة تخصيصاً، غالباً /32 لـIPv4 و/128 لـIPv6، لتقليل الضرر على العناوين المجاورة. لكن سياسات الإنترنت المعتادة ترفض غالباً ما هو أطول من /24 و/48.

تفتح خدمة RTBH استثناءً مقصوداً: تقبل host route للعميل من أجل إسقاط محلي، وتمنعه من التحول إلى قابلية وصول عامة. يحتاج الاستثناء إلى مجموعات تغطية محددة، وأطوال مسموحة لكل عائلة، وجلسة ومجتمع معتمدين، ومنطقة تنفيذ، وفعل محلي.

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

يلزم أيضاً تحديد عدد المسارات المتزامنة، والوجهات المحمية، والعمر الأقصى، ومناطق الدخول. لا يميز maximum-prefix العادي بين مسار واحد مدمر وآلاف المسارات الروتينية.

حصر المسار المدمر داخل نطاق التفويض

توصي RFC 7999 بإضافة NO_ADVERTISE أو NO_EXPORT أو ما يماثلهما. تميز RFC 1997 بينهما: يمنع الأول الإعلان لأي peer، ويسمح الثاني بالتوزيع الداخلي لكنه يمنع الخروج من AS أو confederation.

قد يحتاج المزود إلى نشر المسار في كل ingress، أو في مناطق دخول الهجوم فقط. يجب أن يعكس الحصر رسم التنفيذ. حصر ضيق يفشل الدفاع؛ وحصر واسع يسمح بتسرب more-specific.

التسرب خطير حتى إذا تجاهلت الشبكة البعيدة BLACKHOLE، لأن longest-prefix match قد يجذب المرور. وإذا نفذت الإشارة، يتوسع الإسقاط. لذلك توصي RFC 5635 بمرشحات egress.

تنص وثائق FRRouting الحالية على إضافة NO_ADVERTISE تلقائياً عند تلقي BLACKHOLE. هذا دليل على سلوك FRR، لا قاعدة عامة لكل vendor وrelease. قد تحتاج منصة أخرى إلى سياسة صريحة، وقد تمحو قاعدة تستبدل communities قيمة الحماية.

الدليل الصحيح هو Adj-RIB-Out بعد السياسة لكل فئة جار. سطر الإعداد نية؛ والمسار الخارج يبين ما كان الجهاز سيعلنه.

توثيق القناة لا يوثق نية الإسقاط

تحمل COMMUNITIES الكلاسيكية BLACKHOLE، وتسمح RFC 1997 بتعديلها محلياً. وتحذر RFC 7999 من أن BGP لا يمنع على نحو خاص إضافة المجتمع أو حذفه أو تغييره، وأن BGPsec لا يحل سلامته. قد يصبح الإلحاق غير المخول هجوم حرمان من الوصول.

حماية الجلسة مفيدة ضد انتحال النظير، لكنها لا تثبت أن النظام اختار الخدمة الصحيحة. ويجيب RPKI عن علاقة أخرى: prefix وorigin AS وmaxLength. لا يوقع المجتمع ولا قرار الحادث.

قد يكون /32 مشروع للحجب RPKI Invalid إذا سمحت ROA بالـ/24 فقط. تطلب RFC 7999 ألا تحجب origin validation الإعلانات المشروعة خطأً. لكن إعفاء كل مسار يحمل BLACKHOLE يجعل سمة قابلة للتعديل مفتاح تجاوز. كما أن تمديد كل ROA حتى /32 أو /128 يوسع مجموعة more-specific التي قد تصبح Valid.

اقترحت مسودة فردية عام 2022 كائناً موقعاً باسم RPKI Discard Origin Authorization للفصل بين السلطتين. انتهت المسودة ولا مكانة رسمية لها لدى IETF. هي دليل على المشكلة وليست حماية معيارية منشورة في الشبكات.

يبقى القرار الحالي مركباً: peer identity، ومرشح prefix دقيق، ومعالجة ROV مفسرة، وcommunity، وموافقة incident، ونطاق محلي، وFIB مرصودة. لا يلغي أي عنصر بقية العناصر.

لا تخلط بين أربع أدوات

يسقط RTBH القائم على الوجهة كل ما يتجه إلى الهدف. أما RTBH القائم على المصدر فيجمع discard route وuRPF كي يفشل فحص عنوان المصدر عند مداخل مختارة. تطلب RFC 5635 عدم إعادة استخدام مجتمع الوجهة، وتنصح بأن تأتي محفزات المصدر من أنظمة محلية لإدارة الهجوم لا من الجيران كالمسارات العادية.

يوزع FlowSpec قواعد مطابقة وفعل عبر NLRI مختلف؛ وتقول RFC 7999 إن BLACKHOLE غير مخصص له. يحول sinkhole المرور للمراقبة، ويحاول scrubbing إبقاء المرور المشروع. الحجب الأسود للوجهة لا يحلل ولا ينظف؛ بل يحذف.

تسمية الأداة بدقة تمنع الادعاء بأن الخدمة حُميت بينما هي في الواقع فُصلت لحماية محيطها.

من UPDATE إلى غياب الحزمة

قبل التفعيل، يسجل العقد التشغيلي العميل، والجلسة، وAFI/SAFI، والبادئات، والأطوال، والمجتمع، والاستثناءات المحمية، والمناطق، وقاعدة ROV، والعمر الأقصى، ومسؤول السحب.

ولكل trigger يُحفظ:

  1. UPDATE الخام والوقت والنظير وAS_PATH وorigin وnext hop وكل communities؛
  2. تطابق مرشح التفويض ومصدره؛
  3. حالة ROV والقاعدة الصريحة؛
  4. بند import policy والتعديلات والحصر؛
  5. Adj-RIB-In واختيار Loc-RIB وسببه؛
  6. FIB لكل فئة ingress وحل discard؛
  7. drop counters مع الجهاز والواجهة والدلالة وخط الأساس؛
  8. الحزم قبل حد الإسقاط وبعده؛
  9. Adj-RIB-Out لكل جار يجب ألا يتلقى المسار؛
  10. withdrawal، وحذف FIB، وعودة المسار العادي، واختبارات الخدمة.

يثبت UPDATE الإدخال، وتثبت السياسة القرار، وتثبت RIB الاختيار، وتثبت FIB الأمر التنفيذي، وتثبت الحزم النتيجة. يثبت الإخراج الحصر، ويثبت التعافي انتهاء السلطة.

لا تكفي علامة «blackhole active». فهي لا تفرق بين مسار غير مختار، وnext hop لم يحل إلى discard، ونصف أجهزة لم تُبرمج، وحالة stale بعد السحب. تشجع RFC 7999 حفظ UPDATEs طويلاً؛ ويحتاج التدقيق كذلك إلى السياسة وFIB والعدادات والموافقة.

اختبار التضحية واختبار العودة

يجب تمرير canary prefix آمن عبر كل نوع جلسة وعائلة ومنطقة ومنصة وإصدار. يقبل الاختبار الحالة المخولة، ويرفض بادئة خارجية وجلسة خاطئة وطولاً غير مسموح. ويفحص الحصر وFIB والعدادات والأثر المحدود والعودة بعد السحب.

يُوقف التفعيل إذا غاب incident حي، أو كان الهدف محمياً، أو تعذر تفسير ROV، أو فُقد الحصر، أو ظهر المسار في eBGP غير متوقع، أو اختلفت FIB بين الإصدارات، أو غاب expiry أو withdrawal owner.

يبدأ rollback بالسحب ولا ينتهي عنده. يجب إزالة discard من كل FIB، وعودة المسار العادي، ونجاح probes، وبقاء الوصلة تحت السيطرة. قد يكون التحويل قابلاً للعكس، لكن المسؤولية لا تُستعاد إذا انتهت صلاحية الأدلة.

مصادر