Dyn جعلت اعتماد DNS مشكلة مساءلة في استمرارية الإيرادات

ملخص

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

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

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

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

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

كان فريق الاستعداد للطوارئ الحاسوبية الأمريكي قد حذر بالفعل من تهديدات نمط Mirai في تنبيه أكتوبر 2016 بشأن خطر DDoS المتزايد من Mirai والبوت نتات الأخرى. جاء التحذير قبل حدث Dyn ووصف أجهزة IoT مخترقة تُستخدم في هجمات DDoS. هذا التوقيت مهم. لم يخلق هجوم Dyn مشكلة بوت نت IoT؛ بل أظهر كيف يمكن لحجم البوت نت أن يحول مزود DNS مشترك إلى نقطة اختناق للوصول العام.

سيطرة Dyn كانت حقيقية لكنها لم تكن كاملة

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

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

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

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

استمرارية الإيرادات تبدأ بقابلية الوصول

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

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

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

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

DNS الثانوي هو انضباط، ليس مجرد مربع اختيار

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

توضح وثائق BIND حول نقل المناطق من اتحاد أنظمة الإنترنت و RFC 1996 حول إشعار DNS أن خوادم DNS المتعددة لديها آليات طويلة الأمد لتوزيع تغييرات المنطقة. يضيف DNS المُدار الحديث APIs وإدارة حركة المرور وميزات خاصة بالمزود، لكن المشكلة الأساسية تظل المزامنة والسلطة. لا يمكن لشركة أن تفترض أن إضافة بائع ثانٍ دون عملية تحديث مُختبرة ستعمل أثناء انقطاع الخدمة.

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

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

سعة DDoS هي قضية نظام بيئي

أظهر بوت نت Mirai أن خطر DDoS يُخلق بعيدًا عن الضحية. تم تجنيد الكاميرات و DVRs والموجهات وغيرها من الأجهزة في حركة مرور الهجوم لأنها كانت ضعيفة التأمين ومنتشرة على نطاق واسع. ربط تحليل KrebsOnsecurity لعام 2016 لانقطاع Dyn الاضطراب العام بالأجهزة الاستهلاكية المخترقة، وشرح استعراض Cloudflare اللاحق لـ Mirai سبب أهمية بيانات الاعتماد الافتراضية والتعرض للأجهزة. هذه المصادر ليست بديلاً عن حساب Dyn الخاص، لكنها تساعد في شرح لماذا كان حجم الهجوم مشكلة بنية تحتية مشتركة.

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

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

ممارسات مشغل الشبكة مهمة أيضًا. تتناول إرشادات مكافحة الانتحال مثل BCP 38, RFC 2827 و BCP 84, RFC 8704 التحقق من عنوان المصدر، وهو تحكم يساعد في تقليل بعض فئات حركة المرور المسيئة. لم يعتمد Mirai فقط على الانتحال، لكن الدرس الأوسع هو أن مرونة DDoS هي انضباط نظام بيئي. يمكن لمزودي DNS شراء السعة وبناء التنظيف، لكن شبكات الوصول ومصنعي الأجهزة ومزودي السحابة والعملاء جميعهم يؤثرون على حجم الهجوم وتأثيره.

استمرارية الخدمة العامة تضيف واجبًا آخر

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

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

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

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

جودة الإشعار مهمة عندما ينكشف دليل العناوين

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

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

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

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

الدرس على مستوى مجلس الإدارة ليس "اشتر المزيد من DNS"

الدرس على مستوى مجلس الإدارة هو معاملة قابلية الوصول العام كأصل تجاري. DNS و BGP و CDN ودفاع DDoS وشهادات TLS والتحكم في المسجل وحالة الاتصالات كلها تقع قبل الإيرادات. قد تكون مملوكة لفرق تقنية، لكن فشلها يسبب ضررًا تجاريًا وعامًا. لا تحتاج مجالس الإدارة إلى معرفة كل نوع سجل. لكنها تحتاج إلى معرفة ما إذا كانت المنظمة لديها اعتمادات حاسمة دون بديل مُختبر.

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

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

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

الإصلاح الدائم يعني تقليل مجال الفشل المشترك

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

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

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

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

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

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

يجب أن يتضمن التمرين خطوات المسجل. من يمكنه تسجيل الدخول؟ هل أقفال السجل مفعلة؟ هل التغييرات محمية بموافقة متعددة الأشخاص؟ هل يمكن إجراء تغييرات طارئة دون تعطيل ضوابط الأمان؟ هل سجلات DNSSEC DS مفهومة؟ تُظهر إرشادات الممارسات التشغيلية لـ DNSSEC في RFC 6781 لماذا تضيف المناطق الموقعة اعتبارات تشغيلية؛ يمكن لـ DNSSEC تعزيز المصادقة، لكن التغييرات الطارئة غير الحذرة يمكن أن تكسر التحقق. الشركة التي توقع المناطق يجب أن تعرف كيف يتفاعل التجاوز مع التوقيع وإدارة المفاتيح والتفويض قبل الانقطاع.

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

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

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

يجب أن تتطلب العقود أدلة على الحادث، وليس فقط أرقام وقت التشغيل

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

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

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

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

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

يمكن للسلطات العامة نسخ نفس الاختبار

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

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

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

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

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

يجب أن تمتد المساءلة إلى منع البوت نت

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

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

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

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

الحدث التالي المشابه لـ Dyn قد يكون أكثر تجزؤًا

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

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

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

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

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