هجوم Dyn 2016: الاستعانة بمصادر خارجية لـ DNS قد تسبب فشل الوضع ا

ملخص

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مع ذلك، يشتري العملاء DNS المُدار لأن المزود يدعي الخبرة في هذا المجال التشغيلي بالضبط. لذلك، كانت Dyn تمتلك جانب المزود من المرونة: تخطيط السعة، والتنسيق مع المزودين المنبع، وهندسة anycast، وتصميم مجموعة خوادم الأسماء، واتصالات الحالة، ودعم العملاء، واستعداد شريك التخفيف، والأدلة بعد الحادثة. يمكن لحساب مساءلة عادل أن يحمل كلا الفكرتين في نفس الوقت. كان الهجوم خبيثًا وكبيرًا. كانت أعمال 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 Network الخاصة بـ Sony؛ أثرت الهجمات على Dyn، مما تسبب في جعل مواقع الويب بما في ذلك Sony وTwitter وAmazon وPayPal وTumblr وNetflix وجامعة جنوب نيو هامبشاير غير قابلة للوصول أو متقطعة لعدة ساعات.

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

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

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

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

تحكم العميل كان حقيقيًا لكن غير متساوٍ

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

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

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

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

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

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

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

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

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