تعتمد البنية التحتية الحديثة للشركات على تشغيل تطبيقات الويب داخل حاويات معزولة، وقد أصدرت مختبرات Datadog الأمنية إرشادات خاصة لمهندسي السحابة حول كيفية حماية حاويات Docker وعناقيد Kubernetes من ثغرتي PHP2Shell.
مخاطر الاعتماد على صور الحاويات القديمة في بيئات الإنتاج
عندما تُبنى حاوية Docker باستخدام صورة أساسية مثل php:8.3-fpm أو php:8.4-apache قبل تاريخ 21 أكتوبر 2026، فإن المفسر المدمج بداخلها يظل عرضة للاختراق حتى لو تم تحديث النظام المضيف.
خطوات تحديث وإعادة نشر الحاويات بأمان
- تحديث ملف Dockerfile: تحديد وسوم الإصدارات المرقعة صراحةً مثل 8.5.12 و8.4.27 و8.3.36 و8.2.35.
- إعادة بناء الصور دون تخزين مؤقت: استخدام خيار --no-cache لضمان سحب أحدث حزم التوزيعة الأساسية.
- ضبط حدود الذاكرة على مستوى الحاوية: استخدام cgroups كحد أمان خارجي مع الحذر من أوامر RLIMIT التي قد تحفز الثغرة.
- مراقبة العمليات المنبثقة: تفعيل أدوات مراقبة وقت التشغيل لرصد أي محاولة لتشغيل /bin/sh أو bash داخل الحاوية.
في بيئات الحاويات، لا يكفي تعديل الإعدادات؛ بل يجب إعادة بناء الصورة واستبدال كافة الـ Pods العاملة في الإنتاج.
دور البوابات العكسية Ingress Controllers في صد الهجمات
يمكن ضبط بوابات NGINX Ingress أو Envoy لرفض طلبات النماذج التي تحتوي على أسماء حقول تتجاوز الطول الطبيعي أو تتضمن بايتات صفرية (Null Bytes) قبل وصولها إلى حاويات PHP.
أتمتة فحص الثغرات في خطوط أنابيب CI/CD
يُنصح بدمج فاحصات الصور الأمنية في مرحلة البناء لمنع نشر أي حاوية تتضمن نسخة PHP أقدم من تحديثات أكتوبر 2026. ويمكن مراجعة التفاصيل الموثقة عبر دليل Datadog لتأمين الحاويات ضد PHP2Shell.
التعليقات (0)
أضف تعليقك