اختراق Route 53 عام 2018 جعل الثقة بين BGP وDNS اختبارًا للمساءلة

الملخص

سجّل تحليل التوجيه المعاصر لشركة Cloudflare إعلانات غير مصرح بها أكثر تحديدًا بدأت بعد الساعة 11:05 بالتوقيت العالمي المنسق في 24 أبريل 2018 لبادئات /24 داخل نطاقات عناوين Route 53 التابعة لـ Amazon. كان الأصل المرصود هو eNet برقم AS10297، ومرّت بعض المسارات عبر Hurricane Electric برقم AS6939. استمرت حالة التوجيه غير الطبيعية قرابة ساعتين. [1]
كانت الآلية في البنية التحتية للشبكة، لا في الاستعارة المجازية. فالشبكات التي قبلت المسارات الأكثر تحديدًا أرسلت حركة المرور الخاصة بجزء من خدمة DNS الموثوقة التابعة لـ Amazon نحو أصل خاطئ. وقدّمت الأنظمة التي تم الوصول إليها عبر ذلك المسار إجابات زائفة لـmyetherwallet.com، مما سمح لاستعلام نطاق شرعي بتوجيه المستخدمين نحو نقطة نهاية مزيفة. [1]
لم يُثبت الحادث أن Amazon هي من أصدرت المسارات، أو أن جميع عملاء Route 53 تأثروا، أو أن BGP وحده تجاوز TLS. فقد أوردت Cloudflare أن نقطة النهاية المزيفة استخدمت شهادة غير موثوقة عادةً، وكان على المستخدم تجاوز تحذير المتصفح حتى ينجح مسار سرقة بيانات الاعتماد الموصوف. [1]
ربطت سجلات موارد الأرقام والسجلات الخاصة فضاء العناوين بـ Amazon وAS16509، لكن أجهزة التوجيه تصرفت بناءً على إعلانات المسارات المقبولة. ظلت حقيقة السجل دليلًا أساسيًا بينما حددت حالة المسار الجارية تسليم الحزم. وهذا الفرق هو سطح المساءلة المركزي. [7]-[9][14]
يمكن للتحقق من أصل RPKI أن يحوّل سجل التفويض إلى قرار توجيه قابل للتنفيذ. ووثّقت AWS لاحقًا تغطية واسعة لـ ROA ورفض المسارات غير الصالحة وفق RPKI في شبكتها. وتُظهر تلك التصريحات اللاحقة اتجاهًا للإصلاح، لكنها لا تثبت الضوابط الدقيقة المنشورة على كل شبكة ذات صلة في أبريل 2018. [3][4][17]-[19]
يمكن لـ DNSSEC أن يمكّن المحللين المتحققين من توثيق بيانات DNS الموقعة، لكنه لا يجعل مسار BGP مشروعًا، ولا يعيد إمكانية الوصول، ولا يحمي منطقة لم يتم توقيعها والتحقق منها بشكل صحيح. ولا تُثبت الحزمة العامة الحالة التاريخية الكاملة لـ DNSSEC للنطاق المعني، لذا تعالج هذه المقالة DNSSEC كضابط شرطي محدود. [5][6]
تُجيب RouteViews وRIPE RIS وRIS Live وCAIDA BGPStream وRIPEstat وسجلات أجهزة التوجيه والتقاطات استجابات DNS وأدلة الشهادات على أسئلة مختلفة، ولا يثبت أي منها وحده الحادث كاملًا أو نية المشغل أو كل ذاكرة تخزين مؤقت مسمومة أو كل خسارة. [8]-[13]
تتبع المساءلة السيطرة العملية على إصدار المسارات، وتصفية الاستيراد، وتفويض الموارد، والمراقبة، وDNS الموثوق، والتحقق في المحلل، وأمان النطاق، والتواصل بشأن الحادث، وإثبات الإصلاح. ولا يمكن إسنادها بمعاملة سجل واحد أو مجمّع مسارات واحد أو اسم شركة واحد بوصفه صاحب السيادة على المسار بأكمله.

التقت طائرتا تحكم في فشل واحد مرئي للمستخدم

جمع الحادث بين نظامين لا يلتقي بهما المستخدمون عادةً إلا من خلال نتائجهما.

الأول هو التوجيه بين النطاقات. يتيح بروتوكول بوابة الحدود للشبكات المستقلة تبادل معلومات إمكانية الوصول. ويقول إعلان المسار إن الشبكة قادرة على توصيل حركة مرور بادئة عبر مسار معين. ولا يوفر BGP بذاته إثباتًا تشفيريًا شاملًا بأن الأصل مصرح له بالإعلان عن فضاء العناوين هذا. ويضيف المشغلون سياسات وفلاتر وبيانات سجلات وتحقق RPKI ومراقبة وعلاقات أعمال حول البروتوكول. [14][15]

والثاني هو نظام أسماء النطاقات. تجيب خدمة DNS الموثوقة عن الأسئلة المتعلقة بسجلات النطاق، بينما يوجه المحللون المتكررون أسئلتهم إلى الخوادم الموثوقة، ويخزنون الإجابات مؤقتًا ويعيدونها إلى العملاء. وقد وفرت Route 53 عناوين الخوادم الموثوقة المعنية بهذا الحدث. وإذا أُعيد توجيه الحزم الموجهة إلى عناوين تلك الخوادم قبل بلوغها الخدمة الشرعية، فقد يتلقى المحلل إجابة من نظام ما كان ينبغي أن يكون موثوقًا أبدًا. [1][5][6]

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

وتلك قرارات منفصلة:

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

عبر حادث أبريل 2018 كل حد من هذه الحدود بالتتابع. لهذا فإن وصفه بأنه مجرد «اختطاف BGP» غير مكتمل، بينما وصفه بأنه مجرد «تسميم DNS» يخفي فشل التحكم في المسار الذي جعل الخادم الزائف قابلًا للوصول.

السلسلة أيضًا هي السبب في عدم إمكانية إسناد المساءلة إلى جهة واحدة لمجرد ظهور علامتها التجارية في اسم الخدمة. كانت Amazon تتحكم في موارد عناوينها وعمليات Route 53 والمراقبة والاتصالات ونشر أمن المسارات لاحقًا، لكنها لم تكن تتحكم في كل متحدث خارجي بـ BGP. وكان الأصل غير المصرح به وعلاقاته مع المزودين الأعلى يتحكمون في نقاط أخرى. كما تحكم مشغلو المحللين المتكررين ومشغل النطاق وسلوك المتصفح أو المستخدم في الحدود اللاحقة.

والسرد الدقيق يتبع القدرة والأدلة عبر السلسلة.

ما يثبته سجل التوجيه العام

وصف المنشور التقني لشركة Cloudflare إعلانات BGP المرصودة بين الساعة 11:05 و12:55 بالتوقيت العالمي المنسق تقريبًا. وأدرج خمس بادئات /24 في فضاء عناوين Amazon وأظهر مسارات تشمل AS10297 وAS6939. وكانت النطاقات الشاملة الشرعية من نوع /23 مرتبطة بـ Amazon وAS16509. [1]

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

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

رأت مجمعات Cloudflare عناوين Route 53 داخل تلك النطاقات. وخلال نافذة التوجيه غير الطبيعية، قدمت الأنظمة المجيبة سلوكًا خاصًا بـmyetherwallet.com، بما في ذلك عنوان زائف، بينما أنتجت بعض الاستعلامات أخطاءً. وأوردت Cloudflare أيضًا أن محللها 1.1.1.1 تأثر في مواقع مختارة، ولم يكن يتعين على المحلل أن يكون مشغلًا من شبكة قبلت الإعلان الخاطئ مباشرة إذا كان مساره إلى الخادم الموثوق يعبر شبكة قبلته. [1]

ويدعم السجل عدة استنتاجات محدودة:

كانت البادئات أكثر تحديدًا من مسارات Amazon الشاملة.
لم يطابق رقم النظام الذاتي المرصود AS16509 الخاص بـ Amazon.
تضمن مسار نشر واحد على الأقل AS6939.
كانت العناوين مستخدمة من قبل DNS الموثوق لـ Route 53.
لوحظت إجابات زائفة لنطاق واحد عبر المسار المحوَّل.
كانت حالة التوجيه متفاوتة جغرافيًا وليست متطابقة عالميًا.

والسجل نفسه لا يثبت:

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

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

توفر RouteViews بيانات تحديث مؤرشفة لشهر أبريل 2018، وتوثق RIPE RIS وRIS Live نظام قياس آخر لتحديثات BGP، ويقدم CAIDA BGPStream منصة بحثية لتحليل أحداث التوجيه، ويوفر RIPEstat عروضًا للموارد والتوجيه لـ AS16509 وAS10297. ويمكن لهذه الأنظمة مجتمعة اختبار اتساق السرد مع أدلة التوجيه العامة. [8]-[13]

ودورها الصحيح هو التأييد وإعادة البناء، وينبغي ألا تحوّل المقالة نقاط المراقبة المحدودة لمجمع ما إلى ادعاء انتشار شامل.

لماذا لم تفرض حقيقة السجل حقيقة الحزم

كانت موارد العناوين المعنية مرتبطة بـ Amazon، وكان لهذا الارتباط أهمية؛ فقد أعطى المشغلين والمحققين مرجعًا للحكم على الأصل غير المتوقع.

لكنه لم يجبر كل جهاز توجيه على رفض الإعلان.

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

وبدون تلك الخطوة، يمكن أن يتعايش سجل دقيق مع مسار غير دقيق.

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

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

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

لذلك يحتاج المشغل المسؤول إلى توفيق لا مجرد تسجيل:

هل كل بادئة صادرة مغطاة بالتفويض المقصود؟
هل يسمح الحد الأقصى لطول البادئة فقط بالأكثر تحديدًا المقصودة؟
هل تُولَّد فلاتر العملاء والأقران من بيانات حديثة موثقة؟
هل ترفض أجهزة التوجيه الأصول غير الصالحة وفق RPKI؟
هل تقارن المراقبات الأصول الحية مع سلطة الموارد؟
هل يستطيع الفريق التواصل سريعًا مع المزود الأعلى وحائز المورد ذي الصلة؟
هل تبقى خدمة DNS الموثوقة قابلة للوصول من شبكات مستقلة؟

أصبح حدث 2018 ضارًا لأن المسار الجاري وأدلة الموارد تباعدا مدة كافية لتصل حركة DNS إلى نظام إجابة غير مصرح به.

التحقق من أصل BGP قوي ومحدود

يوفر RPKI طريقة لربط بادئات IP بأنظمة ذاتية مرخصة للأصل عبر كائنات موقعة. ويحدد تفويض أصل المسار أي رقم نظام ذاتي يمكنه إصدار بادئة والحد الأقصى للطول المسموح به، وتتحقق الأطراف المعتمدة من تلك الكائنات، ويمكن لأجهزة التوجيه تلقي بيانات الأصل المتحقق منها وتصنيف مسارات BGP إلى صالحة أو غير صالحة أو غير موجودة. [17]-[19]

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

لنفترض أن Amazon فوّضت AS16509 بإصدار البادئة الشاملة وحددت حدًا أقصى للطول يستبعد /24 غير المصرح به، فإن مسارًا من AS10297 لتلك البادئة /24 يجب أن يكون غير صالح وفق RPKI، ويمكن لشبكة تفرض التحقق من الأصل رفضه.

هذه آلية وقائية ملموسة تحوّل سلطة موارد الأرقام إلى قرار توجيه.

لكنها ليست سردًا كاملًا لأمن توجيه الإنترنت.

يقيّم التحقق من الأصل العلاقة بين البادئة وطولها ونظام الأصل الذاتي، لكنه لا يوثق كل رقم نظام ذاتي في المسار؛ فقد يظل الأصل الصحيح طرفًا في تسريب مسار، وقد تصدّر سياسة سيئة مسارات خارج نطاقها المقصود، وقد يبطل ROA قديم أو خاطئ مسارات شرعية، وقد تظل شبكة لا تجري التحقق تقبل وتروّج مسارًا غير صالح. [15]-[20]

يعرّف RFC 7908 تسريبات المسارات بأنها نشر خارج نطاق السياسة المقصودة، ويضيف RFC 9234 أدوار BGP وخاصية Only-to-Customer كآلية لاحقة للإشارة إلى أنماط تسريب معينة وتقييدها. وتعالج هذه الضوابط علاقات سياسة المسار التي لا يثبتها التحقق من الأصل. [16][20]

والحد التاريخي لا يقل أهمية.

كتبت AWS في 2021 أن أكثر من 99% من فضاء عناوين IPv4 وIPv6 لديها مغطى بـ ROAs وأنها تسقط المسارات غير الصالحة وفق RPKI في نقاط حضورها. وفي 2025 وصفت AWS تنفيذًا أوسع لـ RPKI مع فحوصات أمان إضافية وعمل مستمر على تفويض المسار. [3][4]

تُظهر هذه التصريحات ما تقول AWS إنها نشرته لاحقًا، لكنها لا تثبت تغطية ROA الدقيقة أو الأطوال القصوى أو إنفاذ العبور الخارجي أو إعداد المراقبة في 24 أبريل 2018.

لذلك تستخدم المقالة المسؤولة المنشورات اللاحقة كأدلة إصلاح:

تعترف AWS باختطاف أصل BGP بوصفه خطرًا ماديًا على الشبكة.
تحدد AS16509 بوصفه رقم نظام ذاتي رئيسي لـ AWS.
تصف ROAs ورفض المسارات غير الصالحة بوصفهما ضابطين.
توثق فحوصات الأمان لأن أخطاء RPKI يمكن أن تؤثر هي نفسها على الاتصال.
تقر بأن أمن التوجيه يتطلب تعاونًا عبر الشبكات.

ولا ينبغي للمقالة إعادة كتابة تلك الضوابط اللاحقة إلى الوراء في الحادث.

تظل تصفية المسارات مسؤولية المشغل

RPKI هو أحد مصادر بيانات التفويض، كما يتحكم المشغلون في ما يقبلونه من العملاء والأقران والمزودين الأعلى.

يناقش RFC 7454 الممارسات التشغيلية لأمن وتصفية BGP، وتصف MANRS إجراءات منع الإعلانات غير الصحيحة ومنع حركة المرور المنتحلة ودعم التنسيق وتمكين التحقق العالمي. [15][22]

السؤال المهم ليس ما إذا كانت الشبكة تملك وثيقة بعنوان «سياسة توجيه»، بل ما إذا كانت السياسة الجارية على الجلسة المعنية سترفض الإعلان المرصود.

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

ولكل ضابط تكاليف صيانة وأنماط فشل.

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

لهذا تطلب المساءلة أدلة على التشغيل الحالي:

مجموعة بادئات العملاء المعتمدة ومصدرها.
تاريخ ومالك آخر مراجعة.
الفلتر المجمّع المثبت على جهاز التوجيه.
اختبار يظهر رفض البادئات الأكثر تحديدًا غير المصرح بها.
تنبيه ناتج عن تمرين مضبوط لأصل غير متوقع.
مسار اتصال وسحب يعمل خارج ساعات العمل.

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

ضخّم DNS الموثوق خطأ التوجيه

لم تكن العناوين المحوَّلة عناوين خوادم ويب عادية، بل كانت تابعة للبنية التحتية لـ DNS الموثوق في Route 53.

وضخّم هذا الدور الأثر.

فالمحلل المتكرر الذي يبحث عن إجابة لـmyetherwallet.comكان يحتاج أولًا إلى الوصول إلى الخادم الموثوق للنطاق. وإذا أعاد BGP توجيه حركة ذلك الخادم، فقد يتلقى المحلل سجلًا زائفًا، وقد يخزنه مؤقتًا ويقدمه للعملاء حتى انتهاء صلاحيته أو تصحيحه. ويمكن لمستخدم لا تقبل شبكة وصوله المسار غير المصرح به مباشرة أن يتلقى إجابة مسمومة من محلل متكرر قبلها. [1]

وهذا يخلق خريطتين جغرافيتين:

الشبكات التي اتبعت مساراتها إلى الخادم الموثوق الإعلان غير المصرح به.
المستخدمون الذين حصل محللوهم المتكررون على إجابات وخزنوها عبر تلك المسارات.

تتقاطع الخريطتان لكنهما غير متطابقتين.

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

لذلك ينبغي أن تشمل أدلة المساءلة:

تحديثات BGP وحالة الأصل.
الاستعلامات المرسلة إلى العناوين الموثوقة المتأثرة.
استجابات DNS المرصودة من عدة محللين ونقاط رصد.
سلوك TTL وانتهاء ذاكرة التخزين المؤقت.
نتائج تحقق DNSSEC حيث ينطبق.
ملاحظات الشهادات عند نقطة النهاية المعادة.
طوابع زمنية لسحب المسار وتصحيح الإجابات واستعادة الذاكرة المؤقتة.

ويُظهر الحدث أيضًا لماذا يُعد DNS الموثوق اعتماد شبكي عالي التأثير؛ فتغيير مسار يؤثر على مجموعة صغيرة نسبيًا من عناوين الخوادم يمكن أن يؤثر على تحليل النطاقات المفوضة إلى تلك الخوادم. وهذا لا يعني أن كل منطقة في Route 53 تأثرت؛ فقد لاحظت Cloudflare سلوكًا مركّزًا على نطاق واحد. [1]

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

يجيب DNSSEC عن سؤال ثقة مختلف

يتيح DNSSEC للمحللين التحقق من أن بيانات DNS أصلية ضمن سلسلة ثقة موقعة، وتصف وثائق Route 53 سير عمل توقيع تسجيل النطاق والمنطقة المستضافة، وتوضح أن المحلل المتحقق يمكنه رفض بيانات DNS التي لا تتحقق مقابل السلسلة. [5][6]

وهذا الضابط ذو صلة مباشرة بإجابات DNS الزائفة.

لكنه ليس ضابط BGP.

لا يقرر DNSSEC أي نظام ذاتي يمكنه الإعلان عن بادئة IP، ولا يجعل الخادم الموثوق قابلًا للوصول، ولا يمنع تحويل حركة المرور، بل يتيح للمحلل المتحقق أن يسأل ما إذا كانت بيانات DNS التي تلقاها أصلية تشفيريًا.

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

أما إذا كانت المنطقة غير موقعة أو لم يتحقق المحلل، فلن يوفر DNSSEC تلك الحماية.

لا تثبت حزمة المصدر الحالة التاريخية الكاملة لـ DNSSEC لـmyetherwallet.comفي 24 أبريل 2018، وسيكون من غير اللائق الادعاء بأن النطاق كان يملك أو يفتقر إلى إعداد محدد دون أدلة أولية إضافية.

والصياغة المسؤولة شرطية:

يمكن لـ RPKI المساعدة في التحقق من أصل المسار.
يمكن لـ DNSSEC المساعدة في التحقق من بيانات DNS.
يمكن لـ TLS توثيق نقطة النهاية للمتصفح.
ولا يحل أي منها محل الآخر.

لا يكون التصميم الطبقي قوة إلا عندما تتوقف التطبيقات عند الفشل؛ فإجابة DNS المتحقق منها المرسلة عبر مسار محوَّل يمكن أن تظل أصلية إذا جاءت من الموقّع الشرعي، ويجب أن تفشل إجابة DNSSEC غير الصالحة عند محلل متحقق، ويمكن لإجابة DNS صالحة أن تشير إلى تطبيق مخترق، ويمكن لمسار صحيح أن يحمل محتوى خبيثًا، ويمكن تجاهل تحذير الشهادة.

وتتطلب المساءلة اختبار سلوك الفشل عند كل حد.

ظل TLS إشارة توقف مرئية

أوردت Cloudflare أن نقطة النهاية المزيفة قدمت شهادة غير موثوقة عادةً، وظهر اسم النطاق صحيحًا في بيانات الشهادة، لكن الشهادة كانت موقعة ذاتيًا بدلًا من أن تكون مربوطة بسلطة موثوقة، وينبغي للمتصفح عرض تحذير. [1]

ويضع هذا الدليل حدًا مهمًا.

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

ولا يعفي ذلك فشل التوجيه أو DNS؛ فلا ينبغي وضع المستخدمين أمام نقطة نهاية مزيفة، لكنه يمنع الادعاء المبالغ فيه بأن BGP جعل TLS غير ذي صلة.

يُظهر الحادث بدلًا من ذلك دفاعًا طبقيًا تحت الضغط:

كان يمكن لفحوصات أصل المسار إيقاف التحويل قبل DNS.
كان يمكن لتحقق DNSSEC إيقاف إجابة DNS مزورة لمنطقة موقعة.
كان يمكن لتحقق TLS إيقاف الثقة في نقطة النهاية المزيفة.
كان يمكن لسلوك واجهة المستخدم والتطبيق إيقاف تقديم بيانات الاعتماد.

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

وينبغي لمراجعة المساءلة أن تحافظ على الدفاعات التي نجحت مع فحص سبب فشل الضوابط السابقة، وإلا ستعاقب المقالة الأدلة الدقيقة بتسطيح كل طبقة في فشل واحد كامل.

تتبع المسؤولية السيطرة العملية

شمل الحادث عدة أطراف بقدرات مختلفة.

الأصل غير المصرح به ومشغلو شبكته

كانت الشبكة المحددة بوصفها الأصل المرصود تتحكم في جلسة BGP التي ظهرت منها المسارات الأكثر تحديدًا أو مرتبطة بها. وستشمل الأدلة ذات الصلة إعداد جهاز التوجيه والتوثيق والوصول إلى الحسابات وسجلات التغيير وعلاقات العملاء وسجلات الحادث. وتُظهر المجمعات العامة إعلانات منسوبة إلى رقم نظام ذاتي، لكنها لا تحدد الفرد أو النظام الذي أصدرها. [1][9]

المزودون الأعلى الناشرون وشبكات العبور

تحكم المزودون الأعلى في فلاتر الاستيراد وتفويض بادئات العملاء وإعدادات الحد الأقصى للبادئات والتحقق من الأصل والنشر. ويُثبت المسار المرئي عبر AS6939 ملاحظة مسار لا حكم عقد كامل أو إهمال. والسؤال الدليلي هو ما إذا كانت الشبكة تملك ضوابط حديثة كان ينبغي أن ترفض الإعلان وما إذا كانت تلك الضوابط تعمل.

Amazon Web Services

تحكمت AWS في مورد العنوان وخدمة Route 53 وسجلات الموارد العامة وموقف أمن المسارات ومراقبة الخدمة والتواصل مع العملاء. وكان يمكنها نشر ROAs ومراقبة الأصول غير المتوقعة والتنسيق مع الأقران وتوثيق الإجراءات التصحيحية، لكنها لم تكن تستطيع برمجة كل جهاز توجيه خارجي أحاديًا. وتصف منشورات RPKI اللاحقة التحقق الداخلي والتعاون الصناعي، وهو ما يعكس تلك الحدود المشتركة. [3][4]

مشغلو المحللين المتكررين

تحكم مشغلو المحللين في مسارات المزودين الأعلى التي تستخدمها خوادمهم، وما إذا كانوا يتحققون من DNSSEC، وكيف يخزنون الإجابات، وما يحتفظون به من بيانات قياس، ومدى سرعة مسح البيانات الزائفة المعروفة. ولم يصدر هؤلاء بادئات Route 53 أو يوقعوا منطقة النطاق.

مشغل النطاق

تحكم مشغل النطاق في خيارات التفويض وتوقيع DNSSEC وإدارة السجلات ونشر TLS والتواصل مع المستخدمين والاستجابة للحوادث، لكنه لم يتحكم في قبول BGP عالميًا. ولا ينبغي للمقالة استنتاج إعداد DNSSEC التاريخي دون أدلة.

مشغلو المتصفحات والتطبيقات

تحكم مشغلو المتصفحات والعملاء في التحقق من الشهادة وسلوك التحذير، وشكلت حمايتهم حدًا لاحقًا بعد فشل التوجيه وDNS بالفعل.

المستخدمون

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

خريطة المسؤولية ليست صيغة للوم المتساوي، بل خريطة للأدلة والقدرة.

ينبغي للكشف التوفيق بين التفويض والمسار والإجابة

لن يراقب نظام كشف مفيد طبقة واحدة فقط.

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

وقد تكون كل إشارة مشوشة أو غير مكتملة.

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

والجواب هو الربط مع سلطة التغيير:

هل المسار مغطى بتفويض حالي؟
هل يطابق الإعلان نشرًا معتمدًا؟
هل تراه مجمعات مستقلة متعددة؟
هل تعيد فحوصات DNS الموثوق بيانات موقعة متوقعة؟
هل تتوافق إجابات المحلل وسلاسل الشهادات؟
هل أكد مالك مسؤول التغيير؟

وينبغي للتنبيه الاحتفاظ بالأدلة المستخدمة في القرار؛ فقد يختفي حدث BGP عابر قبل بدء التحقيق. وتوفر أرشيفات RouteViews وRIPE RIS سجلات تاريخية، بينما تضيف سجلات أجهزة التوجيه المحلية والتقاطات DNS تفاصيل خاصة بالمشغل. [10]-[13]

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

لوحة المراقبة بدون مالك استجابة ليست ضابطًا.

يجب أن يغلق الإصلاح السلسلة كلها

سحب المسار غير المصرح به ضروري، لكنه قد لا يكمل الاستعادة.

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

لذلك ينبغي لسجل الإغلاق الفصل بين:

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

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

ويقول الإغلاق الدقيق أي طبقة تعافت وما تبقى.

تقدم تصريحات نشر RPKI اللاحقة لـ AWS أدلة على اتجاه طويل الأجل واحد، إذ تصف تغطية ROA ورفض المسارات غير الصالحة وفحوصات الأمان. والسؤال الصحيح التالي هو ما إذا كانت الاختبارات الحالية تُظهر الضوابط وهي ترفض مسارًا غير مصرح به أكثر تحديدًا مكافئًا دون حجب الخدمة الشرعية. [3][4]

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

يصبح الإصلاح مسؤولًا عندما يكون قابلًا للاختبار.

أجندة أدلة عملية

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

سلطة موارد الأرقام

أي سجلات RIR تغطي فضاء العناوين؟
أي أرقام أنظمة ذاتية مصرح لها بإصدار كل بادئة؟
ما الأطوال القصوى المسموح بها؟
من يملك إنشاء ROA ومراجعته وانتهاءه وتصحيحه الطارئ؟
هل تُعتمد تغييرات التفويض بشكل مستقل؟

قبول المسار

أي بادئات يمكن لكل عميل الإعلان عنها؟
ما المصدر الذي يولد الفلتر؟
ما سرعة تحديثه؟
هل تُرفض المسارات غير الصالحة وفق RPKI؟
هل تُقبل المسارات غير المعروفة بموجب سياسة خطر موثقة؟
هل تُختبر حدود الحد الأقصى للبادئات والأكثر تحديدًا؟

المراقبة

أي مجمعات وتغذيات داخلية تكشف الأصول غير المتوقعة؟
ما عتبة التنبيه؟
هل يمكن للتنبيه تمييز ترحيل مخطط من اختطاف؟
هل يوجد مالك استجابة على مدار 24 ساعة؟
هل تُحفظ ملاحظات المسار وDNS؟

DNS الموثوق

هل تُفحص عناوين الخدمة من شبكات مستقلة؟
هل المناطق موقعة حيث يتطلب الأمر؟
هل يرفض المحللون المتحققون البيانات الزائفة؟
هل يمكن للمشغلين تحديد أي ذاكرات تلقت إجابة خاطئة؟
هل التواصل مع العملاء مستقل عن مسار DNS المتأثر؟

ثقة نقطة النهاية

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

إثبات الإصلاح

هل أُجري تمرين لأصل غير مصرح به؟
هل رفضته الفلاتر والتحقق؟
هل نبهت المراقبة قبل بلاغات المستخدمين؟
هل ظل DNS الموثوق صحيحًا؟
هل أكمل فريق الاستجابة مسار الاتصال والسحب؟
هل سُجلت الاستثناءات والإخفاقات وإعادة الاختبار؟

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

لماذا سلسلة التحكم هذه محددة

سؤال المساءلة ليس ببساطة ما إذا كان BGP غير آمن؛ ففي هذا الحدث حدد التوجيه بين النطاقات أي خادم أجاب عن استعلامات جزء من فضاء عناوين DNS الموثوق لـ Route 53، ثم أعاد النظام الذي تم الوصول إليه بيانات DNS زائفة لنطاق واحد، مخلقًا مسارًا نحو نقطة نهاية مزيفة حيث قدم TLS حد تحذير منفصل. وتجمع هذه السلسلة بين تفويض موارد الأرقام وقبول المسار وسلامة DNS الموثوق وسلوك المحلل وتوثيق نقطة النهاية. [1][14]

لذلك تشمل سلسلة تحكم Route 53:

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

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

قيود المصادر

منشور Cloudflare في 24 أبريل 2018 هو المصدر التقني المعاصر المركزي، ويتضمن البادئات المرصودة والأوقات ومسارات الأنظمة الذاتية واستخدام عناوين Route 53 وسلوك DNS وحد الشهادة. وكانت Cloudflare مراقبًا ومشغل محلل متأثرًا، لا محكمة محايدة أو منظمًا، ولم تر مجمعاتها كل جهاز توجيه. [1]

ويشرح مقال Cloudflare اللاحق عن كشف الاختطاف نموذج المراقبة لديها ويستخدم الحدث نفسه مثالًا، وهو مفيد لسياق الآلية والإصلاح، لا كتأييد مستقل لكل تفصيل في 2018. [2]

ومنشورا AWS لأمن التوجيه في 2021 و2025 وصفان مباشران لضوابط لاحقة، ولا يثبتان حالة الضوابط الدقيقة في 2018 أو التبني الخارجي. [3][4]

وتشرح وثائق AWS Route 53 DNSSEC وسلوك الخدمة كما وُثّق لاحقًا، ولا تثبت حالة التوقيع والتحقق التاريخية الكاملة للنطاق المعني. [5][6]

وتوفر وثائق نطاقات AWS IP وRIPEstat سياق الموارد، ولا تثبت النية أو كل علاقة تشغيلية. [7]-[9]

وتوفر RouteViews وRIPE RIS وRIS Live وCAIDA BGPStream قدرات قياس عامة، وتعتمد رؤيتها على الأقران ونقاط التجميع، ولا تكشف كل مسار خاص أو إعداد جهاز توجيه أو ذاكرة DNS أو قرار مشغل. [10]-[13]

وتعرّف RFCs البروتوكولات وفئات الخطر والآليات الموصى بها، وليست دليلًا على أن مشغلًا معينًا نشر ضابطًا أو كان مدينًا بواجب قانوني معين. [14]-[20]

وتشرح وثائق ARIN وMANRS الأدوات والأعراف التشغيلية، ولا تثبت امتثال كل طرف في الحدث. [21][22]

لا تثبت هذه المقالة نية خبيثة من مشغل مسمى، أو مسؤولية جنائية، أو إهمالًا، أو إخلالًا تعاقديًا، أو عدد ضحايا موثقًا، أو خسارة إجمالية موثقة، أو تسميم ذاكرة كاملًا، أو إصلاحًا دائمًا عبر كل شبكة. ولا تدعي أن RPKI أو DNSSEC أو TLS وحده كان سيمنع كل الضرر.

هذه القيود جزء من سجل المساءلة، وتحدد ما يحتاجه تحقيق أقوى.

الخلاصة

أظهر اختطاف Route 53 في 2018 كيف يمكن لخلاف بين سلطة موارد الأرقام وحالة المسار الجارية أن يعبر إلى DNS وثقة المستخدم.

ربطت سجلات التسجيل والتخصيص البادئات بـ Amazon، ومع ذلك قبلت أجهزة التوجيه إعلانات أكثر تحديدًا من أصل آخر، ووصل المحللون المتكررون إلى خوادم عبر تلك المسارات، ووجهت إجابات زائفة لـmyetherwallet.comالمستخدمين نحو نقطة نهاية مزيفة، وظل TLS حد تحذير لاحق بدلًا من أن يختفي.

وأجابت كل طبقة عن سؤال مختلف:

بيانات السجل: من يحوز المورد؟
ROA وRPKI: أي نظام ذاتي يمكنه إصداره؟
سياسة BGP: أي مسار ستقبله الشبكة؟
مراقبة المسارات: ماذا أعلن الإنترنت؟
DNS الموثوق: ما الإجابة التي قدمها الخادم الذي تم الوصول إليه؟
DNSSEC: هل بيانات DNS أصلية؟
TLS: هل نقطة النهاية موثقة؟
سلوك المستخدم والتطبيق: هل تتوقف المعاملة عند الفشل؟

تتبع المساءلة المشغلين الذين كان يمكنهم جعل تلك الإجابات دقيقة وإبقاءها متوافقة.

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

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

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

الاختبار النهائي تشغيلي: أعلن مسارًا غير مصرح به أكثر تحديدًا في تمرين آمن، وتحقق من صحة بيانات التفويض، ورفض الفلاتر له، وتنبيه المراقبة، وبقاء إجابات DNS أصلية، وحفاظ العملاء على فحوصات الشهادات، ووصول المستجيبين إلى الأقران المسؤولين، وشرح الأدلة المحفوظة لكل قرار.

إذا تعذر إظهار التمرين، يظل إدخال السجل مجرد وعد بشأن المسار، وإذا أمكن إظهاره، يصبح السجل جزءًا من ضابط يعمل.