كلاودفلير وصف المؤسس المشارك والرئيس التنفيذي ماثيو برينس الفواق الذي حدث يوم الثلاثاء 18 نوفمبر والذي أدى إلى تعطيل حركة المرور العالمية على الإنترنت لساعات بأنه فشل المنظمة أسوأ انقطاع منذ عام 2019قائلًا إن عملاق إدارة حركة المرور لم يواجه مشكلة تسببت في توقف تدفق غالبية حركة المرور الأساسية عبر شبكته منذ أكثر من ست سنوات.
قال برينس: “إن انقطاع التيار الكهربائي مثل اليوم أمر غير مقبول. لقد صممنا أنظمتنا لتكون شديدة المرونة في مواجهة الفشل لضمان استمرار تدفق حركة المرور دائمًا. عندما كان لدينا انقطاعات في الماضي، كان ذلك يؤدي دائمًا إلى بناء أنظمة جديدة أكثر مرونة”. “بالنيابة عن الفريق بأكمله في Cloudflare، أود أن أعتذر عن الألم الذي سببناه للإنترنت اليوم.”
انقطاع Cloudflare بدأت الساعة 11.20 صباحًا بالتوقيت العالمي المنسق (6.20 صباحًا بتوقيت شرق الولايات المتحدة) يوم الثلاثاء عندما بدأت شبكتها تواجه إخفاقات كبيرة في توصيل حركة المرور الأساسية، والتي ظهرت لمستخدمي الويب العاديين كصفحة خطأ تشير إلى فشل شبكة Cloudflare عندما حاولوا الوصول إلى موقع العميل. لم تنشأ المشكلة بسبب هجوم إلكتروني أو نشاط ضار، ولكن بسبب تغيير بسيط يؤثر على ملف يستخدمه Cloudflare إدارة البوت نظام الأمان.
تتضمن Cloudflare Bot Management نموذجًا للتعلم الآلي يقوم بإنشاء “نتائج” الروبوتات لأي طلب يعبر الشبكة – يتم استخدام هذه النتائج من قبل العملاء للسماح أو عدم السماح للروبوتات بالوصول إلى مواقعهم. وهو يعتمد على ملف تكوين الميزة الذي يستخدمه النموذج للتنبؤ بما إذا كان الطلب تلقائيًا أم لا، ولأن مشهد الروبوتات ديناميكي للغاية، يتم تحديثه ودفعه مباشرة كل بضع دقائق على وجه التحديد حتى يتمكن Cloudflare من التفاعل مع الروبوتات والهجمات الجديدة.
نشأ الانقطاع من تغيير في أذونات نظام قاعدة البيانات مما تسبب في قيام قاعدة البيانات المذكورة بإخراج إدخالات متعددة في ملف تكوين الميزة. زاد حجم الملف بسرعة وتم نشره للأسف على جميع الأجهزة التي تشتمل على شبكة Cloudflare. كان من المفترض أن تقرأ هذه الأجهزة – التي توجه حركة المرور عبر الشبكة – الملف لتحديث نظام إدارة الروبوتات، ولكن نظرًا لأن برامجها لها حد لحجم ملف الميزة، فقد فشلت عندما ظهر ملف الميزة الأكبر من المتوقع، مما تسبب في تعطل الأجهزة.
ارتباك DDoS
وقال برينس إن الفرق التقنية في Cloudflare اشتبهت في البداية في أنها تشهد هجومًا واسع النطاق لرفض الخدمة الموزعة (DDoS) بسبب عاملين. أولاً، تعطلت صفحة الحالة الخاصة بـ Cloudflare، والتي تتم استضافتها خارج بنيتها التحتية دون أي تبعيات، عن طريق الصدفة. ثانيًا، في بداية فترة الانقطاع، شهدت Cloudflare فترات قصيرة من التعافي الواضح للنظام.
ومع ذلك، لم يكن هذا نتيجة نشاط الجهة التهديدية – بل كان يحدث لأنه تم إنشاء ملف الميزة كل خمس دقائق من خلال استعلام يعمل على مجموعة قاعدة بيانات ClickHouse، والتي كانت في حد ذاتها في طور التحديث لتحسين إدارة الأذونات.
وبالتالي، لم يتم إنشاء الملف المراوغ إلا في حالة تشغيل الاستعلام على جزء محدث من المجموعة، لذلك كل خمس دقائق كانت هناك فرصة لإنشاء ونشر ملفات ميزات عادية أو غير طبيعية.
وقال برينس: “لقد جعل هذا التقلب من غير الواضح ما كان يحدث، حيث كان النظام بأكمله يتعافى ثم يفشل مرة أخرى، حيث تم توزيع ملفات التكوين الجيدة أحيانًا والسيئة أحيانًا على شبكتنا”. “في البداية، قادنا هذا إلى الاعتقاد بأن هذا قد يكون ناجمًا عن هجوم. وفي نهاية المطاف، كانت كل عقدة ClickHouse تولد ملف تكوين سيئًا واستقر التقلب في حالة الفشل.”
استمرت هذه الأخطاء حتى تمكن الفريق الفني من تحديد المشكلة وحلها عن طريق إيقاف إنشاء ونشر ملف الميزة السيئة، وإدراج ملف “جيد معروف” يدويًا في قائمة انتظار التوزيع، ثم إيقاف تشغيل الوكيل الأساسي وتشغيله مرة أخرى. بعد ذلك، بدأت الأمور تعود إلى طبيعتها اعتبارًا من الساعة 2.30 ظهرًا فصاعدًا، وعاد عدد الأخطاء الأساسية على شبكة Cloudflare إلى وضعها الطبيعي بعد حوالي ساعتين ونصف الساعة.
المخاطر والمرونة
على الرغم من أن Cloudflare نفسها لم تتعرض للهجوم من قبل جهة تهديد، إلا أن انقطاع الخدمة لا يزال يمثل مشكلة خطيرة تتعلق بالمخاطر السيبرانية مع الدروس التي يمكن تعلمها ليس فقط في Cloudflare، ولكن بين جميع المؤسسات، سواء كانوا عملاء أم لا. لقد كشفت عن خطر نظامي أعمق يتمثل في أن الكثير من البنية التحتية للإنترنت تقع على أكتاف قليلة فقط.
رايان بولك، مدير السياسات في منظمة غير ربحية مقرها الولايات المتحدة جمعية الإنترنتقال إن تركيز السوق بين شبكات توصيل المحتوى (CDN) قد زاد بشكل مطرد منذ عام 2020: “تقدم شبكات CDN مزايا واضحة – فهي تعمل على تحسين الموثوقية وتقليل زمن الوصول وانخفاض الطلب على النقل. ومع ذلك، عندما تتركز حركة مرور الإنترنت بشكل كبير داخل عدد قليل من مقدمي الخدمة، يمكن أن تصبح هذه الشبكات نقاط فشل فردية تعطل الوصول إلى أجزاء كبيرة من الإنترنت.
“يجب على المؤسسات تقييم مرونة الخدمات التي تعتمد عليها وفحص سلاسل التوريد الخاصة بها. ما هي الأنظمة ومقدمو الخدمات الذين يعتبرون بالغي الأهمية لعملياتهم؟ أين توجد نقاط الفشل الفردية؟ يجب على الشركات استكشاف طرق للتنويع، مثل استخدام العديد من موفري الخدمات السحابية أو CDN أو المصادقة لتقليل المخاطر وتحسين المرونة الشاملة.”
مارتن جرينفيلد، الرئيس التنفيذي لشركة كود أوربيسأضافت منصة المراقبة المستمرة: “عندما يمكن لملف تكوين واحد يتم إنشاؤه تلقائيًا أن يأخذ أجزاء كبيرة من الويب دون اتصال بالإنترنت، فهذه ليست مشكلة Cloudflare بحتة ولكنها مشكلة هشاشة أصبحت متأصلة في كيفية قيام المؤسسات ببناء مجموعات الأمان الخاصة بها.
“تجعل الأتمتة الأمان قابلاً للتطوير، ولكن عندما ينتشر التكوين الآلي على الفور عبر شبكة عالمية، فإنه يؤدي أيضًا إلى توسيع نطاق الفشل. ما يفتقده معظم المؤسسات، ومن الواضح أنه مفقود هنا، هو الضمان الآلي الذي يتحقق من صحة هذه التكوينات قبل بدء التشغيل. إن الأتمتة بدون ضمان هي هشاشة على نطاق واسع، ولا يمكن الاعتماد على بائع واحد أن يصمد أمام استراتيجية مرونة فعالة.”
من جانبه، قال برينس إن Cloudflare ستتخذ خطوات لتقليل فرص ظهور مثل هذه المشكلة مرة أخرى في المستقبل. يتضمن ذلك تعزيز استيعاب ملفات التكوين التي تم إنشاؤها بواسطة Cloudflare بنفس الطريقة التي يتم بها التعامل مع المدخلات التي ينشئها المستخدم، وتمكين مفاتيح إيقاف التشغيل العامة للميزات، والعمل على التخلص من قدرة عمليات التفريغ الأساسية أو تقارير الأخطاء على إرباك موارد النظام، ومراجعة أوضاع الفشل لظروف الخطأ عبر جميع وحدات الوكيل الأساسية الخاصة بها.
