هجوم DDoS على UltraDNS: اختبار استمرارية DNS والمساءلة

الملخص

النطاق المؤكد:سجّلت المراقبة الموزعة في 30 أبريل 2014 تدهورًا مطوّلًا في خدمة DNS الموثوق UltraDNS التابعة لشركة Neustar. ووصفت ThousandEyes تنبيهات بدءًا من حوالي الساعة 08:15 بتوقيت المحيط الهادئ، ورصدت إخفاقات واسعة في تحليل أسماء النطاقات، وزيادة في زمن الاستجابة وفقدان الحزم على المسارات المؤدية إلى خوادم أسماء UltraDNS. وسجّلت Dotcom-Monitor بشكل مستقل أخطاء DNS وعدم استقرار مستمر. [1][3] وتُثبت هذه الملاحظات حدثًا خطيرًا في قابلية الوصول إلى DNS الموثوق، لكنها لا تثبت أن كل عميل أو مستخدم أو منطقة جغرافية أو جلسة تطبيق تابعة لـ UltraDNS قد فشلت للمدة نفسها.
رواية المزوّد:حدّدت تحديثات Neustar المحفوظة لدى SANS Internet Storm Center حركة مرور DDoS ووصفت العمل مع مزوّدي المستوى الأول (Tier-1)، وإضافة خوادم أسماء UltraDNS إلى التخفيف النشط، وتحوّل نواقل الهجوم، وتشبعًا متقطعًا لشبكة غرب الولايات المتحدة أثر على جزء من شريحة PDNS1-PDNS6. ووصفت التحديثات لاحقًا استقرار حركة مرور DNS مع استمرار التخفيف الاستباقي. [2] وتُعد هذه التصريحات أدلة أولية مهمة، لكنها لا تكشف القياس الكامل للحزم، ولا الجهة الفاعلة، ولا الدافع، ولا تغييرات المسارات الدقيقة، ولا كل قرار تشغيلي.
أهمية البنية التحتية:يُعد DNS الموثوق تبعية يمكن أن تفشل بينما يبقى التطبيق وبيئة استضافته سليمين. فقد تحافظ ذاكرات التخزين المؤقت للمحللات على الوصول مؤقتًا لبعض المستخدمين بينما تفشل الاستعلامات الجديدة. وبالتالي يمكن لمزوّد موثوق مشترك أن يربط الإخفاقات عبر علامات تجارية غير مرتبطة للعملاء ويُحدث فجوة بين لوحات معلومات التطبيق وقابلية وصول المستخدم.
حدود التحكم:تحكمت Neustar في تصميم خدمة UltraDNS وتوجيهها وسعتها ومراقبتها وتفعيل التخفيف وتنسيق شركات النقل والتواصل مع العملاء وأدلة الاستعادة. وتحكم مزوّدو المستوى الأول وشركاء التخفيف في التصفية والسعة المتاحة في شبكاتهم. وتحكم العملاء في اختيار المزوّد وتصميم DNS الثانوي وسياسة TTL والمراقبة الخارجية وسلوك التطبيق أثناء فشل التحليل. وتحكم مشغّلو المحللات وشبكات الوصول في الذواكر المؤقتة ومسارات المستخدمين. ولم يتحكم المستخدمون النهائيون في أي من المسار الموثوق المخفي أو مسار العبور.
طبقة الواقع:تحدد سجلات التفويض والنطاقات الخوادم التي ينبغي أن تجيب، وهي سجلات مساءلة وليست أوامر تجعل الحزم تصل إلى تلك الخوادم. أما قابلية الوصول عبر BGP وحالات Anycast وسعة المنبع وسياسة التخفيف وسلامة برمجيات DNS الموثوق فهي التي تحدد ما إذا كان الاسم يُحل. وتختفي أطروحة المقال إذا أزيلت عناصر DNS الموثوق والتوجيه والتخفيف وتركّز المزوّد المشترك وأدلة الاستعادة.

يجب إعادة بناء الحدث من ساعات متعددة

إن أكثر الحسابات العامة فائدة لحدث 30 أبريل 2014 لا يأتي من طابع زمني واحد للحالة، بل من المراقبة المستقلة وتصريحات المزوّد المحفوظة لدى طرف ثالث والملاحظات المأخوذة من شبكات مختلفة.

أبلغت ThousandEyes عن تنبيهات بدأت عند حوالي الساعة 08:15 بتوقيت المحيط الهادئ، وأظهرت اختباراتها إخفاقات DNS وزيادة في زمن الاستجابة للخدمات التي تعتمد على UltraDNS، بما في ذلك ServiceMax وRingCentral وVeeva Systems وSalesforce. وميّز التقرير بين اختبارات DNS غير المخزنة مؤقتًا وسلوك التطبيق، وربط بعض أعراض التطبيق بإخفاقات في تحليل الأسماء. [1] وهذا التمييز مهم لأنه يصف تبعية شبكية بدلًا من مجرد سرد مواقع ويب بدت غير متاحة.

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

حفظت مذكرات SANS سلسلة من تحديثات Neustar. فقد ذكرت تلك التحديثات أن الشركة كانت تتعامل مع حركة مرور DDoS وتنسق مع مزوّدي المستوى الأول وتحسّن التخفيف عند المنبع وتضع خوادم أسماء UltraDNS في تخفيف نشط. وقالت تصريحات لاحقة إن حركة المرور غيّرت نواقلها وحددت تشبعًا متقطعًا لشبكة غرب الولايات المتحدة للعملاء الذين يستخدمون جزءًا من شريحة PDNS1-PDNS6. ووصفت التحديثات في النهاية حركة مرور DNS بأنها مستقرة بينما ظل التخفيف نشطًا. [2]

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

ولذلك يحافظ إعادة البناء المسؤول على فصل الساعات:

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

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

يمكن أن يفشل DNS الموثوق بينما يبقى التطبيق سليمًا

يفصل نظام أسماء النطاقات بين الاسم الذي يطلبه المستخدم والعناوين والخدمات اللازمة للوصول إلى التطبيق. فتنشر الخوادم الموثوقة الإجابات عن النطاقات المفوضة إليها، وتسأل المحللات التكرارية تلك الخوادم عن الإجابات عندما لا تكون المعلومات مخزنة مؤقتًا بالفعل. [13][14]

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

وصفت ThousandEyes هذا السلوك الحساس للتخزين المؤقت في حدث UltraDNS، إذ قد تظل بعض الجلسات النشطة قابلة للاستخدام بينما تفشل محاولات تسجيل دخول جديدة أو محاولات تحليل جديدة. [1] وهذه الملاحظة ليست شرحًا عامًا لـ DNS أُدرج بعد الحدث، بل تفسر لماذا يمكن لمستخدمين مختلفين الإبلاغ عن حالات خدمة مختلفة في اللحظة نفسها.

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

ولأغراض المساءلة يجب قياس التوافر على عدة طبقات:

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

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

يُنشئ DNS الموثوق المشترك اعتمادًا مترابطًا

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

يوضح سجل المراقبة لعام 2014 ذلك الترابط، إذ رأت ThousandEyes تأثيرات مرتبطة بـ DNS لعدة خدمات مختلفة. [1] ويساعد كون هذه الخدمات تشترك في مزوّد موثوق في تفسير مشكلات الوصول المتزامنة دون افتراض أن كل تطبيق كانت له الأعراض نفسها أو أن بنيته التحتية كلها معطلة.

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

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

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

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

توزّع Anycast الخدمة لكنها لا تثبت الاستقلالية

تتيح Anycast لمواقع خدمة متعددة إعلان قابلية الوصول للعنوان نفسه، ويختار التوجيه مسارًا وفقًا لسياسة الشبكة. وتُستخدم على نطاق واسع لـ DNS لأنها يمكن أن تضع الخدمة قريبًا من المستخدمين وتوزع حمل الاستعلام العادي وتمتص بعض الفشل المحلي. وتصف RFC 4786 اعتبارات تشغيل Anycast بما في ذلك التوجيه والمراقبة وقابلية الوصول وسلوك الفشل. [11]

وكانت Neustar قد وصفت تصميم Anycast وسعة فائضة وتوجيه مركز التخفيف قبل الحدث. [7][8] وتلك المواد ذات صلة بنموذج التحكم، فهي تُظهر نوع البنية والوعد التشغيلي الذي يمكن للعملاء توقع أن يحافظ عليه المزوّد بشكل معقول، لكنها ليست قياسًا للحادثة ولا تثبت كيف تصرف كل مسار أو موقع خاص في 30 أبريل.

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

وتجعل تحديثات Neustar المحفوظة لدى SANS هذا الحدود ملموسًا، إذ تذكر تنسيق المستوى الأول والتخفيف النشط وتغير النواقل والتشبع المتقطع لشبكة غرب الولايات المتحدة المؤثر على جزء من شريحة PDNS1-PDNS6. [2] ويوحي الحساب بأن التوجيه والسعة كانا جزءًا من الاستجابة التشغيلية، لكنه لا يكشف تفاصيل كافية لتحديد حركة Anycast الدقيقة أو مواضع المرشحات أو الحمل لكل موقع.

ولذلك ينبغي أن تطلب مراجعة المساءلة أدلة بدلًا من استنتاج المرونة من كلمة Anycast:

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

إن Anycast آلية، وقيمتها المسؤولة تعتمد على استقلالية مساراتها وقابلية مراقبة حالتها وجودة القرارات المتخذة تحت الحمل.

تكون خوادم الأسماء المتعددة مفيدة فقط عندما تختلف مسارات الفشل

تتوقع معايير DNS والإرشادات التشغيلية أن يكون للنطاقات أكثر من خادم موثوق واحد، وتؤكد RFC 2182 على وضع الخوادم الثانوية بحيث لا تشارك في أنماط فشل شبكي وتشغيلي يمكن تجنبها. [12] ويظل المبدأ مهمًا لأن التكرار الموجود في قائمة فقط يمكن أن يختفي أثناء حادثة حقيقية.

فقد تشترك عدة تسميات مرئية لخوادم الأسماء في:

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

ولا يثبت السجل العام أن جميع أسماء خوادم UltraDNS في 2014 اشتركت في كل هذه التبعيات، لكنه يثبت لماذا يجب اختبار السؤال. فقد أشارت تحديثات المزوّد إلى شريحة PDNS1-PDNS6 محددة وإلى تشبع شبكة في منطقة واحدة. [2] وهذه اللغة تجعل أدلة مستوى الشريحة ذات صلة دون إثبات الطوبولوجيا الخاصة الكاملة.

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

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

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

ملصق DDoS لا يكشف متجه الحزم

حددت تصريحات Neustar المعاصرة حركة مرور DDoS. [2] ويدعم ذلك وصف الحادثة كهجوم DDoS، لكنه لا يكشف كل متجه أو معدل حزم أو تجمع مصادر أو نمط انتحال أو مكوّن مستهدف أو أمر تخفيف.

وتشرح مواد CISA كيف يمكن للفيضانات المباشرة وهجمات التضخيم استنفاد سعة الشبكة أو الخدمة، كما تصف تحدي فصل حركة المرور الضارة عن الاستخدام المشروع وقيمة التنسيق المنبعي ورؤية التدفقات والتصفية وتحديد المعدل والتخفيف القائم على التوجيه. [9][10] وتعالج RFC 5358 وإرشادات تصفية الدخول في RFC 3704 وBCP 38 ضوابط يمكنها تقليل إساءة استخدام الخدمات التكرارية وحركة المرور ذات المصدر المنتحل. [15][16][17]

وتؤسس هذه المصادر سياقًا تقنيًا للضوابط، لكنها لا تثبت أن UltraDNS تعرضت لبروتوكول تضخيم معين أو حجم حركة مرور محدد في 30 أبريل. ويصف التقرير الصناعي المعاصر النمو الأوسع لهجمات الانعكاس والتضخيم في 2014، [18] ويضع مصدر استعادي حدث UltraDNS في تلك البيئة. [4] ويجب ألا يتحول السياق إلى أدلة جنائية خاصة بالحدث.

والحدود الصحيحة صريحة:

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

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

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

تحديثات المزوّد أدلة وليست بديلاً عن القياسات

تعد تحديثات Neustar المحفوظة لدى SANS مفيدة بشكل غير معتاد لأنها تكشف أجزاءً من عملية الاستجابة: تنسيق المستوى الأول والتخفيف النشط وتغير النواقل وشريحة مسماة وتشبع إقليمي وصولاً إلى الاستقرار في النهاية. [2] وهي تمنح الجمهور أكثر من تصريح عام بأن المهندسين يحققون.

ومع ذلك، فإن تحديث الحالة هو ادعاء من المشغّل ويجب اختباره مقابل القياسات الداخلية والخارجية.

وسيربط سجل حادثة قوي كل تحديث بما يلي:

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

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

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

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

تتبع المسؤولية الضوابط التي كان يمكن لكل طرف ممارستها

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

Neustar ومشغّل UltraDNS

تحكمت Neustar في بنية وتشغيل UltraDNS، وشملت ضوابطها ذات الصلة تصميم Anycast وتشغيل برمجيات DNS الموثوق وسعة الشبكة وسياسة المسارات والمراقبة وكشف DDoS وعلاقات التخفيف وتصعيد شركات النقل وتحديثات العملاء والتحقق من الاستعادة.

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

شركات نقل المستوى الأول وشركاء التخفيف

تحكمت الشبكات المنبعية في التصفية والسعة ومعالجة المسارات في أنظمتها، وأشارت تحديثات Neustar صراحة إلى العمل مع مزوّدي المستوى الأول. [2] وهذا يجعل التنسيق المنبعي جزءًا من سجل الحادثة.

وتعتمد المسؤولية في هذه الطبقة على العقود الفعلية والتحكم التقني غير المتاحين علنًا هنا، ولا يستطيع المقال توزيع المسؤولية القانونية، لكنه يستطيع تحديد الأدلة المطلوبة: متى حدث التصعيد، وما حركة المرور التي رصدها كل مزوّد، وما التخفيف المتاح، وما المسارات التي تغيرت، وهل ظلت السعة النظيفة كافية.

عملاء UltraDNS

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

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

المحللات التكرارية وشبكات الوصول

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

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

المستخدمون النهائيون

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

تحدد جودة الأدلة قوة الاستنتاج

يحتوي السجل العام على عدة فئات من الأدلة، وكل فئة تدعم استنتاجًا مختلفًا.

تدعم تحديثات المزوّد الأولى ما قالته Neustar إنها لاحظته وفعلته، وهي أقوى ما تكون بالنسبة للاستجابة المعلنة للمزوّد وأضعف ما تكون حيث تغفل القياسات الأساسية.

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

وتدعم تقارير العملاء والتطبيقات الأعراض المرئية، ويمكن أن تُظهر التركّز والأثر التجاري لكنها قد لا تحدد المكوّن الفاشل بدقة.

وتدعم وثائق البنية السابقة للحدث نموذج التحكم، إذ تصف مواد Neustar تصميم Anycast والسعة والتخفيف. [7][8] لكنها لا تثبت إعدادات وقت الحادثة أو الأداء.

وتدعم RFCs وإرشادات CISA التوقعات التقنية. [9]-[17] وهي ليست نتائج خاصة بالحادثة.

ويمكن للتقارير المقارنة اللاحقة توضيح الأنماط المعمارية، فتحليل ThousandEyes لانقطاع UltraDNS منفصل في 2015 مفيد لفهم قياس Anycast وتبعية المزوّد، لكن يجب عدم دمج حدث 2015 في خط زمن 2014. [6]

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

تتطلب استمرارية العميل أكثر من اسم مزوّد ثانٍ

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

وبالنسبة للخدمات ذات النتائج الأعلى، قد تتضمن الخطة المختبرة:

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

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

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

ويحتاج العملاء أيضًا إلى جرد تبعيات محدد بما يكفي للتصرف، فصف يقول «UltraDNS» لا يكفي، ويجب أن يحدد الجرد النطاقات ومجموعات خوادم الأسماء وحسابات المزوّد والعلاقات الثانوية وحالة DNSSEC وتغطية المراقبة وخدمات الأعمال ومالكي الاستعادة.

والهدف ليس إزالة كل تبعية خارجية، بل جعل التبعية مرئية ومتناسبة وقابلة للاختبار.

ينبغي التعبير عن معالجة المزوّد كضوابط قابلة للملاحظة

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

وقد تشمل المعالجة القابلة للملاحظة:

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

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

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

يجب أن تميّز المراقبة بين العقدة السليمة والخدمة القابلة للوصول

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

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

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

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

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

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

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

تفصل عقيدة Heng.lu بين السجلات والخدمة قيد التشغيل

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

لكنها لا تجعل الخدمة متاحة بالإعلان.

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

وطبقة الواقع هي السلوك المرصود:

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

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

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

تبقى الاستنتاجات القانونية والتعاقدية خارج نطاق الأدلة العامة

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

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

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

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

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

من شأن تمرين صارم أن يختبر سلسلة الاعتماد بأكملها

ينبغي تحويل الدرس الدائم من الحدث إلى تمارين.

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

ويجب أن يفعل التمرين الثاني التخفيف ضد حركة هجوم تمثيلية في بيئة اختبار آمنة، ويقيس فقدان الاستعلامات المشروعة وزمن الاستجابة والسعة النظيفة وتقارب المسارات والتراجع.

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

ويجب أن يختبر التمرين الرابع الخدمة الثانوية المستقلة للعميل، ويتحقق من التفويض والمزامنة وDNSSEC والمراقبة وسلوك التطبيق.

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

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

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

الدرس المركزي هو قابلية الوصول الموثوقة القابلة للتحقق

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

وأقوى سجل عام محدود، فقد رصدت المراقبات الخارجية إخفاقات DNS وزمن استجابة وفقدان حزم، وحددت تحديثات Neustar حركة مرور DDoS وتنسيق المستوى الأول والتخفيف النشط وتغير النواقل وتشبعًا متقطعًا لشبكة غرب الولايات المتحدة أثر على جزء من شريحة مسماة. [1][2][3] ولا يكشف الدليل العام المتجهات الدقيقة للحزم أو معدل حركة المرور أو الجهة الفاعلة أو الطوبولوجيا الخاصة أو النطاق الكامل للعملاء أو فعالية المعالجة الحالية.

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

ويقدم مبدأ Heng.lu الاختبار الأخير، فتحدد سجلات التفويض والنطاق السلطة وتحفظ المسؤولية، ولا تثبت الاستمرارية إلا المسارات القابلة للوصول والبرمجيات الموثوقة السليمة والسعة الكافية والتخفيف العامل والمسارات المستقلة وفحوص الاستعادة الخارجية.

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

هجوم DDoS على UltraDNS عام 2014 جعل استمرارية DNS الموثوق اختبارًا للمساءلة