ست طبقات دفاع في منتج واحد
لا يقتصر Imunify360 على كونه مكافحًا للفيروسات. فهو يُكدّس ستة مستويات حماية متكاملة تعزّز بعضها: جدار حماية شبكي، وWebShield (حماية البوتات)، وجدار حماية WAF تطبيقي، وماسح مكافح فيروسات مع تنظيف، وProactive Defense (وقت تشغيل PHP)، وكشف اختراق (IDS/IPS). قوة هذه البنية أن التهديد الذي يتحايل على WAF يمكن وقفه بواسطة Proactive Defense، والتهديد الذي يجتاز وقت تشغيل PHP سيُكتشَف في الفحص التالي. كل طبقة مستقلة لكنها تُغذّي الطبقات التالية.
الطبقات الست بالتفصيل
- جدار الحماية الشبكي مع استخبارات التهديدات: يحجب عناوين IP الخبيثة المعروفة من قاعدة بيانات مُغذَّاة من أكثر من 57 مليون نطاق في شبكة Imunify العالمية (بيانات 2025). حين يهاجم عنوان IP خادمًا في الشبكة، يُحجَب على جميع الخوادم الأخرى في غضون دقائق.
- WebShield وحماية البوتات: يُصفّي حركة HTTP الواردة قبل أن تصل إلى التطبيق — CAPTCHA تكيُّفي، وقوائم رمادية (Graylist)، وحماية DDoS من الطبقة السابعة.
- جدار WAF التطبيقي (ModSecurity + قواعد Imunify): يفحص كل طلب HTTP ويحجب الثغرات المعروفة (الحقن، وتضمين الملفات، وXSS). تُحدَّث القواعد تلقائيًا من خوادم CloudLinux.
- مكافح الفيروسات وماسح البرمجيات الخبيثة: فحص في الوقت الفعلي للملفات المكتوبة حديثًا، وفحص خلفي قابل للجدولة، وتنظيف تلقائي — يحاول Imunify إزالة الكود الخبيث مع الحفاظ على بقية الملف.
- Proactive Defense: وحدة PHP تحلّل سلوك السكريبتات أثناء وقت التشغيل (لا محتواها الثابت فحسب). تحجب أصداف الويب (webshells) المبهمة والأصداف العكسية وتسريب البيانات حتى إن اجتاز الملف فحص مكافح الفيروسات.
- IDS/IPS وإدارة التصحيحات: كشف السلوكيات الشاذة على مستوى النظام، مقرونًا بـ KernelCare لتطبيق تصحيحات نواة Linux دون إعادة تشغيل.
Proactive Defense: إيقاف البرمجيات الخبيثة المبهمة
تُعدّ Proactive Defense الطبقة الأصعب تجاوزًا. فهي لا تفحص الملفات على القرص، بل تعترض تنفيذ PHP في الوقت الفعلي وتفحص أنماط السلوك: محاولات كتابة ملفات خارج جذر الويب (webroot)، ومكالمات exec() وshell_exec() وsystem() وeval() على بيانات غير مُعقَّمة، وحقن SQL من سكريبت يُفترض أن يكتفي بقراءة قاعدة البيانات. الوحدة متاحة لـ Apache وLiteSpeed. قيمتها الرئيسية هي في مواجهة البرمجيات الخبيثة المبهمة: صدفة ويب (webshell) تجتاز أدوات الفحص الثابت لأن كودها مُشفَّر بـ base64 وتُفكَّك عند التشغيل ستُوقِفها Proactive Defense فور محاولتها تنفيذ إجراء خطر. منذ ديسمبر 2024، دمج Imunify360 أيضًا تحسينات ذاكرة وأداء كبيرة تُقلّص بصمة هذه الوحدة على الخوادم ذات الحمل العالي.
KernelCare وإدارة التصحيحات دون إعادة تشغيل
تعتمد إدارة التصحيحات في Imunify360 على KernelCare (التي طوّرتها CloudLinux أيضًا). تُطبّق KernelCare تصحيحات أمان نواة Linux في ذاكرة التشغيل، دون إيقاف الخادم أو المواقع المستضافة. على خادم cPanel مشترك يستضيف 200 عميل، تُشكّل إعادة التشغيل المفروضة لتصحيح النواة نافذة صيانة مُزعجة. تُلغي KernelCare هذا القيد: تعمل النواة بالنسخة المُرقَّعة في غضون ثوانٍ، دون توقف. في أكتوبر 2025، اكتُشفت ثغرة حرجة في مكوّن AI-Bolit لـ ImunifyAV تتيح تنفيذ كود عشوائي على الخوادم التي تحلّل ملفات خبيثة. نشرت CloudLinux التصحيح (v32.7.4.0) تلقائيًا على خوادم Imunify360 النشطة قبل الإفصاح العلني في نوفمبر 2025 — توضيحٌ مباشر لميزة التحديثات التلقائية.
RapidScan وCloudAV: أداء الفحص على نطاق واسع
على خادم يستضيف مئات الغيغابايتات من ملفات العملاء، يستهلك فحص مكافح الفيروسات الكامل اليومي موارد CPU كبيرة. يُعالج Imunify360 هذا بآليتين. RapidScan يُسرّع عمليات الفحص المتكررة بمعدل يصل إلى 20 ضعفًا مقارنةً بالفحص الكامل الأول: فهو يحتفظ ببيانات وصفية محلية وتجزئة سحابية ليُعيد فحص الملفات المُنشأة أو المُعدَّلة منذ المرور الأخير فحسب. CloudAV يُحيل التحليل المعمّق إلى البنية التحتية السحابية لـ Imunify Security، دون استهلاك CPU المحلي للملفات المشبوهة. أما Low Resource Mode (وضع الموارد المنخفضة)، فيُحدّد بصمة RAM بحوالي 100 ميغابايت — مفيد على VPS محدودة الموارد.
النشر: تثبيت Imunify360 على cPanel/WHM
يتمّ التثبيت الرسمي من سطر أوامر SSH بصلاحيات root. لا يوجد مستودع yum يُضاف يدويًا: سكريبت نشر يُنزّل كل شيء ويُهيّئه تلقائيًا.
التثبيت خطوة بخطوة
تنزيل سكريبت التثبيت
من جلسة root: wget https://repo.imunify360.cloudlinux.com/defence360/i360deploy.sh -O i360deploy.sh
تشغيل النشر بمفتاح الرخصة
نفّذ bash i360deploy.sh --key مفتاح_رخصتك. يُحصَل على المفتاح من حسابك في CloudLinux Network (CLN) بعد الشراء. للتجربة المجانية لمدة 14 يومًا، استخدم bash i360deploy.sh --key IPL (IP License — لا يلزم تسجيل CLN للتجربة).
التحقق من تسجيل WHM
سجّل الدخول إلى WHM كـ root، ثم انتقل إلى Plugins → Imunify360. اقبل اتفاقية الرخصة عند أول وصول. تعرض الواجهة فورًا حالة جدار الحماية والفحوصات النشطة والحوادث الأخيرة.
تفعيل Proactive Defense
في WHM Imunify360، انتقل إلى Settings → Proactive Defense وفعّل وضع KILL (يحجب السكريبت الخبيث ويوقفه) بدلًا من وضع LOG (تسجيل فحسب). ابدأ بـ LOG بضعة أيام إن كانت لديك تطبيقات أعمال معقدة لتحديد الإيجابيات الكاذبة قبل التبديل.
تهيئة الفحص المجدوَل
في Malware Scanner → Settings، حدّد التكرار (يُنصح بالفحص اليومي) واستثناءات المجلدات (ذاكرة التخزين المؤقت، النسخ الاحتياطية الضخمة). قد يستغرق الفحص الكامل الأول عدة ساعات بحسب حجم البيانات المستضافة.
تسجيل الرخصة في CLN
رخصة Imunify360 مرتبطة بعنوان IP الخادم وتُسجَّل عبر CloudLinux Network (CLN) — تمامًا كرخصة CloudLinux OS. في حالة الانتقال إلى عنوان IP جديد، يجب نقل الرخصة من بوابة CLN قبل إعادة التثبيت، وإلا دخل الخدمة في وضع مُتدهور.
يدعم Imunify360 AlmaLinux وRocky Linux وRHEL وCloudLinux OS وUbuntu 22/24 وDebian، ويتكامل مع cPanel وPlesk وDirectAdmin أو يعمل بشكل مستقل. منذ نوفمبر 2024، أصبح Ubuntu 24 مدعومًا رسميًا. إن كنت تُشغّل خادمًا بـ SELinux مُفعَّل، ثبّت وحدة سياسة SELinux لـ Imunify360 يدويًا بعد التثبيت (imunify360-selinux عبر yum) — وإلا فلن تبدأ بعض مكوّنات جدار الحماية.
إدارة قواعد WAF وتعارضات OWASP
يعتمد WAF الخاص بـ Imunify360 على ModSecurity بمجموعة قواعد تُديرها CloudLinux. إن كان خادمك يستخدم سابقًا مجموعة قواعد OWASP (شائعة في إعدادات cPanel اليدوية)، عطّل OWASP قبل تثبيت Imunify360: مجموعتا القواعد تُسبّبان تعارضات وحجبًا متتاليًا مشروعًا وإيجابيات كاذبة مُكثَّفة. يُدير Imunify360 قواعده باستقلالية — فهو غير مُصمَّم للتعايش مع OWASP.
استكشاف الأخطاء: رسائل الخطأ الشائعة
للمشكلات الأكثر شيوعًا بعد تثبيت Imunify360 أو تحديثه أسبابٌ محدَّدة وحلول موثَّقة.
حل الأخطاء الشائعة
«Imunify agent is not running»
السبب الأكثر شيوعًا: خدمة imunify360 لم تبدأ بعد إعادة التشغيل أو التحديث. تحقّق بـ systemctl status imunify360 ثم journalctl -u imunify360 -n 50. إن رأيت Tried to start while migrations are not applied، انتظر 2 إلى 5 دقائق — تعمليات ترحيل SQLite تُنفَّذ عند البدء وتحجب الخدمة مؤقتًا. إن استمرت المشكلة، أعِد التشغيل يدويًا: systemctl restart imunify360.
«Failed to connect to rpc socket [Errno 111] Connection refused»
تشير هذه الرسالة (ظهرت بشكل خاص في v8.4.3) إلى فشل مقبس الاتصال الداخلي بين مكوّنات Imunify360. السبب غالبًا تعطّل العملية الرئيسية أثناء ترحيل. الحل: systemctl stop imunify360 && systemctl stop imunify360-pam && systemctl start imunify360. إن تكرّرت المشكلة، تحقّق من صلاحيات /var/run/imunify360/.
«You must install the following extensions before you can edit their values: imunify360» (WHM)
تظهر هذه الرسالة عند تعديل حزمة cPanel على خادم Imunify360 مُثبَّت دون تفعيل إدارة الميزات. أمر الحل: imunify360-agent feature-management native enable. العملية فورية ولا تتطلب إعادة تشغيل.
عدم استقبال إشعارات «Malware detected»
قد يكتشف Imunify360 برمجيات خبيثة دون إرسال تنبيهات البريد الإلكتروني المُهيَّأة. تحقّق أولًا من نشاط خدمة الإشعارات في Settings → Notifications وإمكانية الوصول للعنوان البريدي من الخادم. إن كانت الإعدادات صحيحة، تحقّق من فتح المنفذين 52223 و52224 صادرًا — يستخدمهما Imunify360 للتواصل مع خوادم CloudLinux السحابية.
انقطاع الاتصال بـ `files.imunify360.com` أو `imunify360.cloudlinux.com`
تمرّ التحديثات التلقائية لقواعد WAF وقواعد بيانات توقيعات مكافح الفيروسات عبر هذين النطاقين. إن تعذّر على الخادم الوصول إليهما (جدار حماية صادر مُقيَّد، بروكسي، DNS داخلي)، تتوقف القواعد عن التحديث ويدخل الخدمة في وضع مُتدهور. تحقّق بـ curl -v https://files.imunify360.com وأضف استثناءً صادرًا إن لزم.
غياب إضافة Imunify360 من واجهة WHM
إن لم تظهر قائمة Imunify360 في WHM/cPanel رغم تثبيت ظاهريًا ناجح، فإن إضافة UI غير مُسجَّلة. نفّذ /usr/share/imunify360/scripts/register-plugin.sh (أو المكافئ لإصدارك) وحدّث WHM. تحقّق أيضًا من كون خدمة imunify360 في حالة active (running) قبل تشخيص الواجهة.
الرخص: كيف تعمل
رخصة Imunify360 مرتبطة بعنوان IP الخادم وتُفوتَر حسب عدد المستخدمين (حسابات cPanel وPlesk وما شابه على الخادم). تبدأ الخطط بنحو 14 دولارًا شهريًا لخادم يضمّ حتى 30 مستخدمًا. يتوفّر عرض مستقل (بلا لوحة تحكم) لخوادم Nginx أو Apache الخالصة. يتمّ التسجيل في CloudLinux Network (CLN)، البوابة ذاتها لرخص CloudLinux OS. في حالة الانتقال لعنوان IP جديد، يُعالَج نقل الرخصة مباشرةً من بوابة CLN — لا حاجة لإعادة الشراء. في ServOrbit، رخص Imunify360 متاحة مباشرةً من منطقة العميل، مرتبطةً بعنوان IP الخادم المخصَّص أو VPS السحابي.
Imunify360 مقابل أدوات منفصلة: ما تتجنّبه
| الحاجة | بدون Imunify360 | مع Imunify360 |
|---|---|---|
| جدار حماية شبكي + استخبارات التهديدات | CSF + LFD (إعداد يدوي، لا شبكة عالمية) | مدمج، يُحدَّث تلقائيًا من أكثر من 57 مليون نطاق |
| WAF تطبيقي | ModSecurity + OWASP (قواعد تتطلب صيانة يدوية) | مجموعة قواعد Imunify تُصان وتُدفَع تلقائيًا |
| مكافح فيروسات البرمجيات الخبيثة | ClamAV (فحص فقط، لا تنظيف تلقائي) | فحص + تنظيف تلقائي + CloudAV |
| حماية وقت تشغيل PHP | لا مكافئ متاح بشكل منفصل | Proactive Defense مدمجة |
| تصحيح النواة دون إعادة تشغيل | تحديث يدوي + نافذة صيانة | KernelCare مدمجة |
| إدارة مركزية عبر WHM | أدوات متفرقة، لا واجهة موحّدة | إضافة WHM أصلية، عرض موحَّد للحوادث |
إن كان خادمك يعمل بـ CloudLinux OS (وهو حال معظم خوادم cPanel المشتركة)، يستفيد Imunify360 من تكامل معزَّز مع أقفاص PHP لكل مستخدم (CageFS). يرى كل حساب cPanel بيئة PHP معزولة: البرمجيات الخبيثة التي تعمل في سياق موقع عميل ما لا تستطيع قراءة ملفات العملاء الآخرين. هذه البيئة الوحيدة التي تجمع عزل PHP (CloudLinux) وحماية وقت التشغيل (Imunify360 Proactive Defense) وفحص مكافح الفيروسات في نشر واحد متماسك.
