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 والتجاوز والمراقبة تتطابق مع ادعاءات التوفر الخاصة بهم. سيطرت جهات تصنيع أجهزة IoT والمالكون ومزودو خدمة الإنترنت (ISP) والجهات التنظيمية والمهاجمون على أجزاء منفصلة من مشكلة البوت نت.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

لم يكنNISTIR 8259A خط الأساس لقدرات الأمن السيبراني لأجهزة IoTموجودًا في عام 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 على الفور؟ هل يجب تغيير قيم TTL؟ هل يجب توصيل إشعارات الانقطاع الموجهة للعملاء؟ هل تأخر نشر المنطقة؟ هل تأثرت جميع المناطق؟ هل سجلات DNS للعميل سليمة؟ أي مجموعات خادم الأسماء تدهورت؟ هل كان من المتوقع أن تتكرر المشكلة؟ كلما باع المزود نفسه كبنية تحتية للإنترنت، أصبحت اتصالات الحالة جزءًا من الخدمة.

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

غيرت المخابئ وإعادة المحاولة والتحضير شكل الضرر

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

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

استخدمتنظرة سريعة على الهجوم على DYNمن RIPE Labs قياسات 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 العامة نفس الانضباط التشغيلي. تؤطر مجموعةإرشادات الحرمان من الخدمة (DoS)من المركز الوطني للأمن السيبراني في المملكة المتحدة التحضير حول أربع ممارسات: فهم الخدمة، فهم الدفاعات، إنشاء خطة استجابة، واختبار الاستجابة. يشرحفهم هجمات الحرمان من الخدمةمن CISA مشكلة التوفر الأساسية: لا يمكن للمستخدمين الشرعيين الوصول إلى أنظمة المعلومات أو الأجهزة أو موارد الشبكة.فهم هجمات الحرمان من الخدمة الموزعة والاستجابة لهااللاحق من CISA وFBI وMS-ISAC أوسع من DNS، لكن المبدأ ينطبق: تحتاج المؤسسات إلى تحضير مسبق، وتنسيق مع مزودي الخدمة، وخطوط أساس لحركة المرور، وإجراءات استجابة، وخطط اتصالات.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الدرس الدائم

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

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

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

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