Dyn جعلت DNS المُدار حدًا للمساءلة في استمرارية الإيرادات

ملخص

• مؤكد:في 21 أكتوبر 2016، أبلغت Dyn عن هجمات DDoS ضد بنيتها التحتية لـ DNS المُدار. وجاء في بيانها العام أن الموجة الأولى بدأت حوالي الساعة 7:00 صباحًا بالتوقيت الشرقي، وأثرت على المستخدمين الموجهين إلى خوادم Dyn على الساحل الشرقي للولايات المتحدة، وتم التخفيف منها بعد حوالي ساعتين. بدأت موجة ثانية أكثر عالمية قبل الظهر مباشرة وتم التخفيف منها في ما يزيد قليلاً عن ساعة. وقالت Dyn إن موجة ثالثة حاولت تم التخفيف منها دون تأثير على العملاء.
• ملاحظ:قامت ThousandEyes بقياس معدلات فشل استعلام DNS عالية من نقاط المراقبة العالمية الخاصة بها وأفادت أن حوالي 75% من نقاط المراقبة أرسلت استعلامات لم تجب عليها خوادم Dyn في ذروة الهجوم. ولاحظت أيضًا حوالي 1200 موقع وخدمة متأثرة بين تلك التي يراقبها عملاؤها، ووجدت أن العديد من العملاء الضعفاء كانوا يستخدمون خوادم أسماء Dyn فقط بدلاً من موفري DNS متعددين.
• إسناد محدود:قالت Dyn إن تحليل Flashpoint و Akamai أكد أن أحد مصادر حركة المرور كانت أجهزة مصابة بـ Mirai. أعلنت وزارة العدل لاحقًا عن إقرارات بالذنب من قبل مبتكري Mirai وإقرار منفصل بالذنب من قبل فرد هجوم حصنه الشبكي المستند إلى Mirai في 21 أكتوبر 2016 أثر على Dyn وجعل مواقع بما في ذلك Sony و Twitter و Amazon و PayPal و Tumblr و Netflix و Southern New Hampshire University غير قابلة للوصول أو متقطعة لعدة ساعات. السجل العام لا يثبت أن جهة واحدة أو حصانة شبكية واحدة أو ناقل هجوم واحد يفسر كل حركة المرور التي شهدتها Dyn في ذلك اليوم.
• تقييم:كان الحادث فشل اعتماد مشترك. سيطرت Dyn على منصة DNS المُدارة وشركاء التخفيف والاتصالات وهندسة البنية التحتية. تحكم العملاء في ما إذا كان DNS الموثوق متنوعًا عبر المزودين وما إذا كانت ممارسات TTL و Failover والمراقبة تطابق ادعاءات التوفر الخاصة بهم. سيطر موردو إنترنت الأشياء والمالكون ومزودو خدمة الإنترنت والمنظمون والمهاجمون على أجزاء منفصلة من مشكلة الحصانة الشبكية.

سجل الأدلة وكيفية استخدامه

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

فشل DNS قبل فشل تطبيق الويب

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

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

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

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

كان الاعتماد المشترك مرئيًا في القياسات

تحليل ThousandEyes، هجوم DDoS على بنية Dyn DNS التحتية، يقدم أوضح تفسير عام لاعتماد جانب العميل. شهدت مراقبته ثلاث مراحل: تأثير أولي مركز على الساحل الشرقي للولايات المتحدة، وتأثير عالمي أوسع، ثم تخفيف لاحق مع هجمات مستمرة أو حظر أسود. في ذروة الهجوم، أرسلت حوالي ثلاثة أرباع نقاط المراقبة العالمية استعلامات DNS لم تجب عليها خوادم Dyn. كما أبلغت عن حوالي 1,200 موقع وخدمة متأثرة بين النطاقات التي يراقبها عملاؤها.

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

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

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

قصة AP التي عكسها شيكاغو صن تايمز التقطت التجربة العامة: آثار غير مباشرة للمستخدمين الذين يحاولون الوصول إلى مواقع ويب شهيرة في الولايات المتحدة وأوروبا، حيث كانت Twitter و Netflix و PlayStation Network من Sony بين الخدمات المتأثرة. تقرير الغارديان المعاصر أدرج Netflix و Twitter و Spotify و Reddit و CNN و PayPal و Pinterest و Fox News والصحف الكبرى بين الخدمات التي تم الإبلاغ عن أنها غير متصلة أو معطلة. هذه التقارير مفيدة للنطاق والإدراك العام؛ ليست دليلاً على أن كل خدمة مسماة شهدت نفس وضع الفشل التقني أو نفس المدة.

فشل الوضع المشترك يختبئ داخل DNS "المكرر"

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

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

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

الورقة الافتقار إلى التكرار في حل DNS لمواقع الويب والخدمات الكبرى فحصت التركيز والتنويع في DNS بعد حادثة Dyn. وجدت تركيزًا متزايدًا بين عدد صغير من مزودي DNS وميلًا قويًا للنطاقات لعدم استخدام مزودي إدارة DNS متعددين. في عينتها، كانت نسبة النطاقات التي تستخدم مزودًا واحدًا حوالي 91٪ إلى 93٪ قبل الهجوم، وانخفضت من 92.2٪ إلى 89.4٪ بين أكتوبر 2016 ونوفمبر 2016. بين عملاء Dyn، انخفضت حصة النطاقات غير المتنوعة بشكل حاد بعد الحادثة واستمرت في الانخفاض بحلول مايو 2017.

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

الإرسال المتعدد قوي، لكنه ليس سحريًا

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

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

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

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

نقل Mirai مخاطر جهاز المستهلك إلى البنية التحتية

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

إعلان وزارة العدل لعام 2017، وزارة العدل تعلن عن تهم وإقرارات بالذنب في ثلاث قضايا جرائم حاسوبية تتضمن هجمات DDoS كبيرة، قال إن Paras Jha و Josiah White و Dalton Norman أقروا بالذنب في تشغيل حصانة Mirai الشبكية، التي استهدفت أجهزة إنترنت الأشياء مثل الكاميرات اللاسلكية وأجهزة التوجيه ومسجلات الفيديو الرقمية. قالت وزارة العدل إن Mirai تألف من مئات الآلاف من الأجهزة المخترقة في ذروتها، وأن تورط المبدعين الأصليين مع متغير Mirai الأصلي انتهى عندما نشر Jha الكود المصدري في منتدى إجرامي في خريف 2016. منذ ذلك الحين، قالت وزارة العدل إن جهات أخرى استخدمت متغيرات Mirai في هجمات أخرى.

إعلان وزارة العدل لعام 2020، فرد يقر بالذنب في المشاركة في هجوم إنترنت الأشياء في 2016، ربط حصانة شبكية متغيرة من Mirai بيوم Dyn بشكل أكثر مباشرة. قال إن فردًا، كان سابقًا قاصرًا، أقر بالذنب فيما يتعلق بهجوم سيبراني في أكتوبر 2016. وفقًا لوزارة العدل، استخدم الفرد وآخرون حصانة شبكية لشن عدة هجمات DDoS في 21 أكتوبر 2016 في محاولة لإخراج شبكة PlayStation من Sony؛ أثرت الهجمات على Dyn، مما تسبب في عدم إمكانية الوصول إلى مواقع بما في ذلك Sony و Twitter و Amazon و PayPal و Tumblr و Netflix و Southern New Hampshire University أو متقطعة لعدة ساعات.

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

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

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

NISTIR 8259A خط الأساس لقدرة الأمن السيبراني لأجهزة إنترنت الأشياء اللاحقة لم تكن موجودة في 2016 ولا ينبغي التعامل معها كالتزام قانوني رجعي لـ Dyn. لا تزال مفيدة كدليل على ما تعلمه النظام البيئي لتقييمه: تحديد الجهاز، والتكوين الآمن، وحماية البيانات، والوصول المنطقي، وقدرة تحديث البرامج، والوعي بحالة الأمن السيبراني، والتوثيق. نجح Mirai لأن العديد من الأجهزة لم تستطع إدارتها كمشاركين مسؤولين في الإنترنت.

سيطرة العميل كانت حقيقية لكن غير متساوية

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

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

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

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

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

كان على الاتصالات أن تخدم جمهورين

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

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

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

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

التخزين المؤقت وإعادة المحاولات والتحضير غيرت شكل الضرر

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

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

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

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

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

إرشادات DDoS العامة تعزز نفس الانضباط التشغيلي. مجموعة إرشادات حرمان الخدمة من المركز الوطني للأمن السيبراني في المملكة المتحدة تؤطر التحضير حول أربع ممارسات: فهم الخدمة، فهم الدفاعات، إنشاء خطة استجابة، واختبار الاستجابة. فهم هجمات حرمان الخدمة من CISA تشرح مشكلة التوفر الأساسية: لا يمكن للمستخدمين الشرعيين الوصول إلى أنظمة المعلومات أو الأجهزة أو موارد الشبكة. فهم والاستجابة لهجمات حرمان الخدمة الموزعة من CISA و FBI و MS-ISAC اللاحقة أوسع من DNS، لكن المبدأ ينطبق: تحتاج المنظمات إلى تحضير مسبق، وتنسيق مع مزودي الخدمة، وخطوط أساس لحركة المرور، وإجراءات استجابة، وخطط اتصالات.

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

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

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

الحد القانوني أضيق من الدرس التشغيلي

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

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

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

إشارة السوق بعد الحادثة

بعد شهر من الهجوم، أعلنت Oracle أنها وافقت على الاستحواذ على Dyn. البيان الصحفي لـ Oracle وصف Dyn بأنها مزود رائد لأداء الإنترنت و DNS قائم على السحابة، وقال إن شبكتها تقود 40 مليار قرار تحسين حركة مرور يوميًا لأكثر من 3,500 عميل مؤسسي، وسمت عملاء بما في ذلك Netflix و Twitter و Pfizer و CNBC. لا ينبغي تفسير الاستحواذ كنتيجة للهجوم دون دليل؛ البيان لم يقل ذلك. لا يزال سياقًا مفيدًا لدور Dyn في السوق. لم تكن هذه خدمة هواة متخصصة. كانت منصة DNS مُدارة رئيسية للشركات الرقمية البارزة.

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

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

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

تعطي قضية Dyn القادة عدة اختبارات تظل مفيدة.

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

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

استراتيجية TTL والتخزين المؤقت:هل تعكس TTLs DNS حاجة المنظمة الفعلية للمرونة مقابل تحمل الانقطاع؟ هل تم إعطاء السجلات الأكثر استقرارًا عمر تخزين مؤقت كافٍ لتقليل الاعتماد القابل للتجنب على عمليات البحث الموثوقة المتكررة أثناء مشكلة مزود عابرة؟

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

المراقبة:هل يمكن للمنظمة التمييز بين فشل DNS الموثوق، ومشاكل المحلل المتكرر، ومشاكل CDN، وفشل الأصل، وفشل التطبيق؟ هل يتم إجراء الاختبارات من عدد كافٍ من الشبكات والمناطق لاكتشاف مشكلة إرسال متعدد أو إقليمية DNS؟

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

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

التعرض للبوت نت:بالنسبة للمنظمات التي تصنع أو تنشر أو تدير أجهزة متصلة، هل بيانات الاعتماد الافتراضية، والتحديث الآمن، وهوية الجهاز، والإبلاغ عن الثغرات، ودعم نهاية العمر مصممة لمنع أسطول الأجهزة من أن يصبح سعة DDoS لشخص آخر؟

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

الدرس الدائم

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

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

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

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