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

الملخص

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

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

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

بيان DYN المحفوظ حول هجوم DDoS في 21 أكتوبر 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، نقل حركة المرور، تفعيل المزودين الثانويين، أم الانتظار؟ هل APIs متاحة؟ هل تحديثات الحالة على بنية تحتية مستقلة عن DNS المتأثر؟ متى سيأتي التحديث التالي؟

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

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

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

جعل Mirai مساءلة البوتنت أمرًا لا مفر منه

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

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

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

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

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

يمكن أن تصبح روايات الانقطاع قصصية بسرعة. يقول مستخدم أن Twitter معطل. يقول آخر أن Spotify يعمل. يقول ثالث أن المشكلة إقليمية. يقول مزود أن التخفيف جارٍ. يساعد القياس في تحويل تلك الملاحظات إلى هندسة. قامت 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 متعدد المزودين دون انتهاك شروط الدعم؟ هل APIs وتنسيقات المنطقة محمولة؟ هل يدعم المزود ترتيبات DNSSEC عبر المزودين؟ هل يمكن للعميل الحصول على السجلات اللازمة لإعادة بناء تأثير الانقطاع الجزئي؟

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

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

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

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

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

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

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

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

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

ثم يجب على الفريق اختبار التغيير. هل يمكن تقديم السجلات بشكل صحيح من المزود الثانوي؟ هل تتصرف الحلول التكرارية كما هو متوقع؟ هل يتحقق DNSSEC؟ هل ما زالت تطبيقات الهاتف المحمول، APIs، تكاملات 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 للشركات، والمحللين العامين، ومحلل ISPs، وشبكات الهاتف المحمول، ومواقع مراقبة السحابة. يجب أن يراقبوا أيضًا الفرق بين حل 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، وأقفال المسجل، أو اعتماديات التطبيق بحذر. خطة تجاوز فشل مسؤولة تتضمن لذلك المسار للعودة إلى الخدمة العادية، والأدلة على أن الخدمة العادية آمنة، والتواصل الذي يخبر المستخدمين أن المشكلة قد انتهت. درس DYN ليس فقط كيفية الابتعاد عن مسار مهاجم. إنه كيفية إثبات أن المؤسسة يمكنها إدارة دورة حياة الاعتماد بالكامل تحت الضغط.

تمت ترجمة هذا المقال بواسطة BTW Media Intelligence باستخدام الذكاء الاصطناعي وإدارة الترجمة. راجع الشروط والأحكام الخاصة بنا للحصول على التفاصيل.