تراخيص أمن الخوادم

Imunify360 هو الأوسع نطاقًا: جدار حماية لتطبيقات الويب يرشّح الطلبات الواردة، وماسح يعثر على الملفات المصابة داخل حسابات العملاء وينظّفها، وحماية من هجمات التخمين على تسجيل الدخول إلى اللوحة والبريد، وبيانات سمعة عناوين IP، كل ذلك في واجهة واحدة. وعلى خادم مشترك يستحيل فيه تدقيق مئات مواقع العملاء موقعًا موقعًا، هذا التجميع هو جوهر الفكرة. أما CPGuard فيعمل داخل لوحة التحكم نفسها، فيجري الفحص وإدارة جدار الحماية وتدقيق الإعدادات في واجهة اللوحة بدل وحدة تحكم منفصلة؛ وإن كان فريقك يقضي يومه أصلًا داخل تلك اللوحة، فلا لوحة قيادة ثانية عليه تعلّمها. وcxs يفعل شيئًا أضيق وأحدّ: يفحص الملفات لحظة رفعها ويطابقها مع توقيعات خبيثة معروفة، فيلتقط web shell — وهو الملف الذي يزرعه المهاجم كي ينفّذ أوامر على خادمك — قبل أن يُنفَّذ أصلًا. وحين تُستغلّ إضافة قديمة، فهذه عادةً هي الطبقة التي تمسك بالحمولة قبل أن تعمل.

تتداخل الثلاثة في مواضع، لكن لا أحد منها يغني عن الآخر. ودليل تقريبي: إن كنت تبيع استضافة مشتركة، فالجمع بين طبقة فحص وجدار حماية واسعة وبين تفتيش الملفات لحظة رفعها اقتران منطقي؛ أما على VPS يشغّل تطبيقًا واحدًا فغالبًا يكفي أحدها. وتشغيل جدارَي حماية على الخادم نفسه دون التوفيق بين مجموعتَي قواعدهما ينتج إنذارات كاذبة وانقطاعات يصعب تشخيصها فعلًا، فاحسم من يملك أي طبقة قبل أن تثبّت شيئًا. أما الجانب التجاري فيعمل كما في بقية اللوحة: يرتبط الترخيص بعنوان IP الخادم، والتثبيت أمر واحد، والتفعيل تلقائي من رصيدك المدفوع مسبقًا، وتغيّر أنت عنوان IP حين ينتقل الخادم فيتوقف العنوان القديم فورًا. كما يمكن إنشاء الترخيص وتجديده ونقله عبر واجهة REST API إن كنت تديره من WHMCS أو من لوحتك الخاصة. وإن جرّبت واحدًا ثم عدلت عنه، فيكفي أن توقف التجديد التلقائي: يعمل الترخيص الشهري حتى نهاية مدته ولا يُخصم بعدها شيء. والأسعار الحالية معروضة في اللوحة.