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

ملخص

• مؤكد:في 21 أكتوبر 2016، أبلغت DYN عن هجمات DDoS ضد بنيتها التحتية لـ DNS المُدار. وأشار بيانها العام إلى أن الموجة الأولى بدأت حوالي الساعة 7:00 صباحًا بالتوقيت الشرقي، وأثرت على المستخدمين الموجهين إلى خوادم DYN على الساحل الشرقي للولايات المتحدة، وتم التصدي لها بعد حوالي ساعتين. وبدأت موجة ثانية أكثر انتشارًا عالميًا قبل الظهر مباشرة، وتم التصدي لها في أكثر من ساعة بقليل. وأفادت DYN أنه تم التصدي لموجة ثالثة محتملة دون تأثير على العملاء.
• مرصود:قاست ثاوزاندآيز معدلات فشل عالية لاستعلامات DNS من نقاط مراقبتها العالمية، وأفادت بأن حوالي 75% من نقاطها أرسلت استعلامات لم تستجب لها خوادم DYN في ذروة الهجوم. كما رصدت حوالي 1,200 موقعًا وخدمة متأثرة من بين ما يراقبه عملاؤها، ووجدت أن العديد من العملاء المعرضين للخطر كانوا يستخدمون خوادم أسماء DYN فقط بدلاً من مزودي DNS متعددين.
• الإسناد المحدود:ذكرت DYN أن تحليلات من فلاش بوينت وأكاماي أكدت أن أحد مصادر حركة البيانات كانت أجهزة مصابة ببرمجية ميراي. وأعلنت وزارة العدل لاحقًا عن اعترافات بالذنب من مبتكري ميراي، واعترافًا منفصلًا بالذنب من فرد أثر هجوم شبكة البوت نت من نوع ميراي الذي شنه في 21 أكتوبر 2016 على DYN وجعل مواقع مثل سوني وتويتر وأمازون وباي بال وتمبلر ونتفليكس وجامعة جنوب نيو هامبشاير غير قابلة للوصول أو متقطعة لعدة ساعات. ولا يثبت السجل العام أن جهة فاعلة واحدة، أو شبكة بوت نت واحدة، أو متجه هجوم واحد يفسر كل حركة البيانات التي شاهدتها DYN ذلك اليوم.
• التقييم:كان الحادث فشلاً نمطيًا مشتركًا للتبعية. سيطرت DYN على منصة DNS المُدار الخاصة بها، وشركاء التصدي، والاتصالات، وبنية البنية التحتية. وتحكم العملاء فيما إذا كان DNS الموثوق متنوعًا عبر مزودين متعددين، وفيما إذا كانت ممارسات TTL وتجاوز الفشل والمراقبة تتوافق مع ادعاءاتهم الخاصة بالتوفر. كما تحكم موردو إنترنت الأشياء ومالكوها ومزودو خدمات الإنترنت والجهات التنظيمية والمهاجمون في أجزاء منفصلة من مشكلة شبكات البوت نت.

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

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

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

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

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

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

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

التبعية المشتركة كانت واضحة في القياسات

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

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

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

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

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

الفشل النمطي المشترك يختبئ داخل DNS "المكرر"

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

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

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

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

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

الأي كاست قوي، لكنه ليس سحرًا

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

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

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

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

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

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

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

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

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

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

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

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

تحكم العملاء كان حقيقيًا، لكنه غير متكافئ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تمنح قضية DYN القادة عدة اختبارات لا تزال مفيدة.

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

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

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

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

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

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

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

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

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

الدرس الدائم

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

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

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

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