ملخص

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

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

الدراسةThe Lack of Redundancy in DNS Resolution by Major Websites and Servicesفحصت تركيز وتنويع DNS بعد حادثة Dyn. وجدت تركيزًا متزايدًا حول عدد صغير من موفري DNS واتجاهًا قويًا للنطاقات لعدم استخدام العديد من موفري إدارة DNS. في عينتها، كانت نسبة النطاقات التي تستخدم مزودًا واحدًا فقط حوالي 91% إلى 93% قبل الهجوم، وانخفضت من 92.2% إلى 89.4% بين أكتوبر 2016 ونوفمبر 2016. بين عملاء Dyn، انخفضت حصة النطاقات غير المتنوعة بشكل حاد بعد الحادث واستمرت في الانخفاض حتى مايو 2017.

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

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

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

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

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

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

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

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

إعلان وزارة العدل الأمريكية لعام 2017 حول Mirai،Justice Department Announces Charges and Guilty Pleas in Three Computer Crime Cases Involving Significant DDoS Attacks، أشار إلى أن Paras Jha وJosiah White وDalton Norman أقروا بالذنب في تشغيل بوتنت Mirai، التي استهدفت أجهزة إنترنت الأشياء مثل الكاميرات اللاسلكية وأجهزة التوجيه ومسجلات الفيديو الرقمية. أوضحت DOJ أن Mirai كان لديها مئات الآلاف من الأجهزة المخترقة في ذروتها، وأن تورط المبتكرين الأصليين مع النكهة الأصلية لـ Mirai انتهى عندما نشر Jha الكود المصدري في منتدى إجرامي في خريف 2016. منذ ذلك الحين، وفقًا لـ DOJ، استخدم فاعلون آخرون نكهات من Mirai في هجمات أخرى.

إعلان وزارة العدل لعام 2020،Individual Pleads Guilty to Participating in Internet-of-Things Cyberattack in 2016، ربط بشكل أكثر مباشرة بوتنة تستخدم نكهة من Mirai بيوم هجوم Dyn. أشار إلى أن فردًا، كان سابقًا قاصرًا، أقر بالذنب فيما يتعلق بهجوم إلكتروني في أكتوبر 2016. وفقًا لـ DOJ، استخدم الفرد وآخرون بوتنة لشن عدة هجمات DDoS في 21 أكتوبر 2016 بهدف إسقاط شبكة PlayStation Network من Sony؛ أثرت الهجمات على Dyn، مما جعل مواقع مثل Sony وTwitter وAmazon وPayPal وTumblr وNetflix وجامعة جنوب نيو هامبشاير غير قابلة للوصول أو متقطعة لعدة ساعات.

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

تحذير CISA حول تهديد MiraiHeightened DDoS Threat Posed by Mirai and Other Botnetsحذر من أن برمجية Mirai الخبيثة كانت تبحث بنشاط عن أجهزة إنترنت الأشياء الضعيفة وأن نشر كود Mirai المصدري زاد من خطر بوتنات جديدة. التقرير اللاحق للتجارة والأمن الداخلي المستضاف من NIST،Enhancing the Resilience of the Internet and Communications Ecosystem Against Botnets and Other Automated, Distributed Threats، أطر المشكلة على مستوى النظام البيئي: الهجمات الموزعة الآلية عالمية، والأدوات الفعالة لا تستخدم على نطاق واسع، يجب تأمين المنتجات طوال دورة حياتها، والحوافز غير متوافقة، ولا يمكن لأي مجتمع من أصحاب المصلحة حل المشكلة بمفرده.

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

الوثيقة اللاحقةNISTIR 8259A IoT Device Cybersecurity Capability Core Baselineلم تكن موجودة في 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 المُدار رؤية مزيج من حركة هجوم، وإعادة محاولات مشروعة من الحلالات، وتأثيرات ذاكرة مؤقتة قديمة، وتغييرات مسار. مشغلو الحلالات التكرارية قد يزيدون ضغط الاستعلامات بإعادة المحاولة عندما تنتهي الاستجابات. يرى المستخدمون اتصالاً متقطعًا وقد يفترضون أن التطبيق معطل. يصبح السرد العام "المواقع الرئيسية معطلة"، بينما تشبه الحقيقة التقنية "بعض الحلالات لا تستطيع الحصول على أو تحديث الاستجابات الموثوقة لبعض النطاقات خلال بعض النوافذ الزمنية".

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

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

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

الأدلة العامة حول DDoS تعزز نفس الانضباط التشغيلي.مجموعة إرشادات رفض الخدمةمن المركز الوطني للأمن السيبراني البريطاني تنظم الاستعداد حول أربع ممارسات: فهم الخدمة، فهم الدفاعات، إنشاء خطة استجابة، واختبار الاستجابة.فهم هجمات رفض الخدمةمن CISA تشرح مشكلة التوفر الأساسية: لا يمكن للمستخدمين الشرعيين الوصول إلى أنظمة المعلومات أو الأجهزة أو موارد الشبكة. الوثيقة اللاحقة من CISA وFBI وMS-ISAC،Understanding and Responding to Distributed Denial-of-Service Attacks، أوسع من DNS، لكن المبدأ ينطبق: المنظمات تحتاج إلى استعداد مسبق، وتنسيق مع مزودي الخدمات، ومراجع حركة المرور، وإجراءات استجابة، وخطط اتصال.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الدرس الدائم

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

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

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

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