مدخل سحابي هادئ يمكن أن يبقى لعدة أشهر
إن Redis المكشوف ليس مجرد مشكلة سوء إعداد؛ ففي بيئات Kubernetes يمكن أن يتحول إلى موطئ قدم دائم لأنشطة البوتنت يصعب اكتشافه ويصعب إزالته.
مقدمة
غالبًا ما يطارد المدافعون عن السحابة الإخفاقات الصاخبة: عمليات تسجيل دخول فاشلة، أو تنبيهات برمجيات خبيثة واضحة، أو سلسلة استغلال مزعجة. النمط الأكثر خطورة يكون أكثر هدوءًا. قد تُترك خدمة لم يكن من المفترض أبدًا أن تواجه الإنترنت متاحةً للوصول، ويمكن لهذا الإغفال الوحيد أن يصبح الخطوة الأولى في اختراق طويل الأمد. في حالة P2PInfect، كان مسار الدخول المبلغ عنه هو Redis مكشوفًا للعامة، مع استمرار النشاط في بعض البيئات لمدة تصل إلى ستة أشهر.
حقائق سريعة
- P2PInfect هي عائلة بوتنت مرتبطة بخدمات Redis المكشوفة.
- شمل الهدف المبلغ عنه بيئات Google Kubernetes Engine.
- أظهرت بعض البيئات التي خضعت للتحقيق وصول المهاجمين إليها لمدة تصل إلى ستة أشهر.
- استُخدمت تنبيهات FortiCNAPP المركبة لاكتشاف نشاط البوتنت المتسق.
- كانت المخاطرة الرئيسية هي انكشاف Redis، وليس وجود خلل مؤكد في منصة Kubernetes.
ما الذي يجعل مسار الهجوم هذا فعالًا
صُمم Redis للشبكات الموثوقة. وإرشاداته الأمنية واضحة: لا تضعه مباشرة على الإنترنت العام. وتكمن أهمية ذلك في أن Redis ليس مجرد مخزن بيانات؛ ففي المكان الخطأ يصبح نقطة مصادقة وتحكم. إذا كان بالإمكان الوصول إلى نسخة منه من أي مكان، فقد تتمكن بوتنت من فحصه، ومحاولة التفاعل معه، واستخدامه كنقطة دخول إلى البيئة المحيطة.
ولهذا ينبغي قراءة هذه الحالة بوصفها قصة انكشاف سحابي، لا مجرد قصة برمجية خبيثة. يستخدم Google Kubernetes Engine نموذج المسؤولية المشتركة: إذ يؤمّن مزود المنصة الخدمة المُدارة الأساسية، بينما يظل العملاء مسؤولين عن تهيئة أعباء العمل، وانكشاف الشبكة، ونظافة الهوية. وبالتالي فإن خدمة Redis عامة داخل العنقود أو بالقرب منه يمكن أن توسع نطاق الضرر حتى عندما لا تكون المنصة نفسها هي المشكلة.
يُعد P2PInfect صعب الدفاع ضده بشكل خاص لأن تصميمه القائم على نظير إلى نظير يقلل الاعتماد على خادم أوامر واحد. عمليًا، قد يجعل ذلك عزل العقد المصابة بشكل نظيف أصعب، وقد يعقد الاكتشاف إذا لم تربط المراقبة بين أنماط الوصول غير المعتادة إلى Redis وسلوك المسح والاتصالات الصادرة طويلة الأمد. وفي الوقت نفسه، لم يُحدَّد مسار الاستغلال الدقيق في هذه الحملة في الملخص، لذا فإن الاستنتاج الأكثر أمانًا هو أن الانكشاف نفسه هو الذي أتاح الفرصة.
حتى وقت كتابة هذا التقرير، لم تُثبت المعلومات العامة بشكل كامل ما إذا كانت بيانات قد سُرقت، أو ما إذا حدث تحرك جانبي، أو ما إذا كان أي مكون تُديره Google قد تأثر مباشرة. وتشير الأدلة المتاحة إلى تحليل مخاطر، لا إلى ادعاء قاطع بحدوث اختراق كامل.
الخلاصة
الدرس مزعج لكنه بسيط: في البيئات السحابية، غالبًا ما لا تكون الثغرة الأخطر هي أحدث علة، بل أقدم خطأ - جعل خدمة حساسة قابلة للوصول من الخارج. عندما يُترك Redis مكشوفًا، لا يحتاج المهاجم إلى ثغرة صفرية مثيرة لإحداث الضرر. كل ما يحتاجه هو طريق للدخول، ووقت للبقاء، وفريق أمني لا يراقب الإشارات الصحيحة.
TECHCROOK
جهاز جدار ناري عتادي: يمكن لجهاز جدار ناري عتادي أن يساعد في تقسيم قواعد البيانات، والحد من الوصول الوارد إلى نطاقات عناوين IP الموثوقة، وإبقاء الخدمات الحساسة خارج الإنترنت العام. وهو خيار عملي لغرف الخوادم الصغيرة، والمختبرات، والمكاتب المتصلة بالسحابة حيث يلزم فرض حدود الشبكة بشكل أوضح.
WIKICROOK
- Redis: قاعدة بيانات وخدمة رسائل داخل الذاكرة، ويجب عادةً تقييدها ضمن الشبكات الموثوقة.
- P2PInfect: عائلة بوتنت ودودة مرتبطة بإساءة استخدام مثيلات Redis المكشوفة.
- Google Kubernetes Engine (GKE): منصة Kubernetes المُدارة من Google Cloud، حيث لا يزال العملاء يتحكمون في العديد من إعدادات الأمان.
- نموذج المسؤولية المشتركة: تقسيم أمن السحابة حيث يؤمّن المزود البنية التحتية ويؤمّن العميل الإعدادات وأعباء العمل.
- تنبيه مركب: إشارة كشف تجمع عدة نقاط قياس لتقليل الإيجابيات الكاذبة وإبراز النشاط الأكثر دلالة.
