DYN جعلت مرونة DNS التوكيدية اختبارًا للمساءلة في تجاوز فشل العملاء

ملخص

• حادث DDoS الذي تعرضت له Dyn في أكتوبر 2016 جعل DNS التوكيدي مشكلة مساءلة في تجاوز فشل العملاء لأن العديد من الخدمات أصبحت غير قابلة للوصول على الرغم من أن مجموعات تطبيقاتها لم تكن الهدف الأساسي.
• سيطرت Dyn على البنية التحتية لإدارة DNS، وشراكات التخفيف، والتواصل مع العملاء، والبيان اللاحق للهجوم. وتحكم العملاء في بنية المجال، وتخطيط DNS الثانوي، والمراقبة، واستعداد السجل، وقواعد قرارات الحوادث.
• أظهرت القياسات والأبحاث المستقلة، بما في ذلك ThousandEyes وأعمال لاحقة حول تكرار DNS، أن تركيز DNS على مزود واحد خلق تعرضًا عمليًا للعديد من المجالات.
• سجلات Mirai و IoT Botnet مهمة، لكنها لا تمحو واجبات المزود والعملاء. مساءلة البوتنت، ومرونة المزود، وتجاوز فشل العملاء هي طبقات مختلفة من نفس مشكلة التوفر العام.
• الدرس الدائم هو أن تجاوز فشل DNS هو نظام تشغيلي يتم التدرب عليه، وليس مربع اختيار في المشتريات. يجب أن يعمل المزودون الثانويون، واختيارات TTL، ومزامنة النطاقات، وDNSSEC، والمراقبة، والإشعار العام معًا قبل الهجوم.

فشل DNS يمكن أن يختبئ خلف التطبيقات السليمة

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

بيان Dyn المحفوظ حول هجوم DDoS في 21/10/2016 وصف هجمات ضد البنية التحتية لـ DNS المُدار، وموجات متعددة، وشركاء تخفيف، وتأثير على العملاء يختلف حسب المنطقة والوقت. هذا البيان هو الأساسي لحساب Dyn، لكنه ليس خريطة خسارة كاملة لكل عميل. يخبرنا أن المزود تعرض للهجوم وأن DNS المُدار هو سطح التشغيل.

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

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

DNS الثانوي ليس مفتاحًا سحريًا

RFC 2182، اختيار وتشغيل خوادم DNS الثانوية، قديم لكنه لا يزال مفيدًا لأنه يذكر مبدأ أساسيًا للمرونة: لا ينبغي أن تشارك خوادم DNS التوكيدية نفس أنماط الفشل المحلي. في DNS المُدار الحديث، يصبح المبدأ أكثر تعقيدًا. قد يستخدم العملاء مزودين متعددين، وشبكات anycast، وDNSSEC، وعناصر تحكم السجل، وإدارة النطاق الآلية، وتكاملات API، وسجلات مرتبطة بـ CDN. التنوع قيم فقط إذا كان تشغيليًا حقيقيًا.

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

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

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

تجاوز فشل العميل يبدأ قبل الهجوم

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

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

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

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

شفافية المزود تحتاج إلى تفاصيل إجراءات العميل

أثناء هجوم مزود DNS، يحتاج العملاء إلى أكثر من مجرد تأكيد أن التخفيف جارٍ. يحتاجون إلى عدم يقين قابل للتنفيذ. أي المناطق متأثرة؟ أي الخدمات متدهورة؟ هل فشلت استجابات التوكيد أم تأخرت؟ هل أنواع سجلات محددة متأثرة؟ هل يجب على العملاء خفض TTLs، أو نقل الحركة، أو تنشيط المزودين الثانويين، أو الانتظار؟ هل واجهات API متاحة؟ هل تحديثات الحالة على بنية تحتية مستقلة عن DNS المتأثر؟ متى سيأتي التحديث التالي؟

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

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

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

Mirai جعل مساءلة البوتنت حتمية

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

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

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

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

القياس يحول الحكاية إلى بنية

يمكن أن تصبح روايات الانقطاع حكائية بسرعة. يقول مستخدم إن تويتر معطل. يقول آخر إن سبوتيفاي يعمل. يقول ثالث إن المشكلة إقليمية. يقول مزود إن التخفيف جارٍ. يساعد القياس في تحويل تلك الملاحظات إلى بنية. قاس ThousandEyes فشل DNS من نقاط مراقبة متعددة. نشر RIPE Labs نظرة سريعة على هجوم Dyn باستخدام ملاحظات RIPE Atlas. ناقش RIPE Labs أيضًا تعقيد DDoS على DNS، بما في ذلك سلوك إعادة المحاولة المتكرر وصعوبة تمييز حركة الهجوم عن استعلامات DNS المشروعة.

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

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

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

استمرارية الخدمة العامة تعتمد على حل الأسماء أيضًا

أثر حدث Dyn على العديد من الخدمات الشهيرة عبر الإنترنت، وفقًا لتقارير معاصرة مثل تقرير Chicago Sun-Times/AP حول هجمات إلكترونية تعطل خدمات الإنترنت وتقرير The Guardian أن هجوم DDoS كبير عطل الوصول إلى مواقع بارزة. تلك الخدمات المذكورة كانت خاصة في الغالب، لكن درس الاستمرارية ينطبق على الخدمات العامة أيضًا. بوابة حكومية، صفحة معلومات طارئة، أداة حجز صحة عامة، نظام تقديم محكمة، أو خدمة ضريبية يمكن أن تختفي أيضًا إذا لم يكن DNS مرنًا.

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

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

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

يجب أن تتطلب العقود أدلة، وليس فقط وقت التشغيل

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

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

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

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

السؤال المسؤول هو من يمكنه إثبات التجاوز

السجل العام يترك العديد من المجهولات: مزيج حركة الهجوم الكامل، كل مجال متأثر، جميع تكوينات العملاء، قرارات السعة الداخلية لـ Dyn، خسائر العملاء الفردية، والواجبات التعاقدية الدقيقة. تلك المجهولات مهمة. تمنع الادعاءات السهلة أن طرفًا واحدًا وحده يملك الضرر بأكمله. كما تجعل معيار المساءلة أكثر عملية: من يمكنه إثبات التجاوز؟

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

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

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

تمرين DNS الحقيقي أصعب من الرسم التخطيطي

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

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

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

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

DNSSEC والأتمتة قد تجعل التجاوز أصعب

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

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

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

صفحات الحالة تحتاج أسماء مستقلة

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

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

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

يجب أن تعامل المشتريات DNS كاعتماد حاسم

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

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

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

المحللات المتكررة والتخزينات المؤقتة تعقد تجربة المستخدم

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

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

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

الوقاية من البوتنت بطيئة، لذا يجب أن يكون استعداد العميل سريعًا

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

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

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

يجب أن يميز السجل العام بين الانقطاع والاعتماد

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

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

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

اختبار المساءلة ممل بالتصميم

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

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

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

مالك التجاوز لا ينبغي أن يكون غامضًا

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

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

التحكم في السجل هو جزء من نفس الاعتماد

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

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

يجب الحفاظ على أدلة العميل للتخصيص لاحقًا

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

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

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

يجب أن يعرف مالكو الخدمة عواقب فشل DNS على المستخدم

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

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

تدريبات DNS يجب أن تشمل الساعة التجارية

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

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