جعلت 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 غير قابلة للوصول أو متقطعة لعدة ساعات. لا يثبت الملف العام أن جهة فاعلة واحدة أو بوت نت واحد أو ناقل هجوم واحد يفسر كل حركة المرور التي رآها Dyn في ذلك اليوم.
• تقييم:كان الحادث فشل اعتماد في الوضع المشترك. كانت Dyn تتحكم في منصة DNS المُدارة الخاصة بها، وشركاء التخفيف، واتصالاتها، وهندسة بنيتها التحتية. كان العملاء يتحكمون في ما إذا كان DNS الموثوق متنوعًا بين المزودين وما إذا كانت ممارسات TTL والتحويل والمراقبة تتطابق مع ادعاءات التوفر الخاصة بهم. كان مزودو إنترنت الأشياء والمالكون ومزودو خدمة الإنترنت والمنظمون والمهاجمون يتحكمون في أجزاء منفصلة من مشكلة البوت نت.

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

تستخدم هذه المقالة البيان الرسمي لـ 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 على بنية DNS التحتية لـ Dyn، يقدم أوضح تفسير عام للاعتماد من جانب العميل. رأت مراقبتها ثلاث مراحل: تأثير أولي مركز على الساحل الشرقي للولايات المتحدة، وتأثير عالمي أوسع، وفي وقت لاحق تخفيف مع هجمات مستمرة أو حجب. في ذروة الهجوم، حوالي ثلاثة أرباع نقاط المراقبة العالمية الخاصة بها أرسلت استعلامات DNS ظلت دون رد من خوادم Dyn. كما أفادت بحوالي 1200 موقع وخدمة متأثرة من بين النطاقات التي تمت مراقبتها من قبل عملائها.

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

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

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

تغطيةAP التي نقلتها Chicago Sun-Timesالتقطت التجربة العامة: آثار متتالية للمستخدمين الذين يحاولون الوصول إلى مواقع ويب شهيرة في الولايات المتحدة وأوروبا، حيث تأثرت Twitter وNetflix وشبكة PlayStation من Sony من بين الخدمات. التقرير المعاصر منThe Guardianأدرج 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 بأنه يتكون أساسًا من أجهزة مضمنة وأجهزة إنترنت الأشياء ويقول إنه وصل إلى ذروة حوالي 600000 إصابة. يدعم المقال أن بساطة طريقة الإصابة والنمو السريع أظهرت أن تقنيات غير متطورة نسبيًا يمكنها اختراق عدد كافٍ من الأجهزة منخفضة الجودة لتهديد أهداف محمية جيدًا.

إعلان وزارة العدل لعام 2017 حول Mirai،وزارة العدل تعلن عن تهم وإقرارات بالذنب في ثلاث قضايا جرائم كمبيوتر تتضمن هجمات 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 غير قابلة للوصول أو متقطعة لعدة ساعات.

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

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

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

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

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

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

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

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

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

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

البحث بعد الحادث قدم نفس النقطة من زاوية أخرى. مقالWhen the Dike Breaks: تشريح دفاعات 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 ضد بنيته التحتية ليس مجرد حادث تقني داخل شبكته. إنها أزمة عميل متزامنة. يحتاج العملاء إلى معلومات كافية لتجنب تفاقم الحدث من خلال ارتجال تغييرات التفويض، أو تقصير TTL، أو نقل النطاقات بشكل غير متسق، أو إغراق الدعم. لذلك يجب أن تشمل دفاتر تشغيل المزود التخفيف، وتقسيم العملاء، ودقة الحالة، وإرشادات للعملاء بمستويات مختلفة من خبرة DNS.

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

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

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

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

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

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

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

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

تقرير 2018 من Commerce and Homeland Security دعم أن حوافز السوق كانت غير متوافقة لمرونة البوت نت. مشكلة حوافز مماثلة كانت موجودة من جانب العميل لـ 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 هو سلطة. التعامل معه كخط إمداد منخفض المخاطر هو كيف تصبح الخدمة المُدارة فشلاً في الوضع المشترك.