قد يبدو الموقع الإلكتروني طبيعيًا تمامًا، بينما تعمل أنظمة الحماية في الخلفية على حظر أنشطة مشبوهة. يتصفح العملاء المنتجات، ويرسلون الاستفسارات، ويحجزون المواعيد دون أن يلاحظوا شيئًا غير معتاد. بالنسبة للشركة، الموقع يعمل كالمعتاد. لكن التقارير الأمنية تكشف جانبًا آخر من الصورة.

خلال فترة رصد امتدت إلى 30 يومًا، سجّلت Cloudflare أكثر من 375.41 مليون طلب ويب، ونقل 7.7 تيرابايت من البيانات عبر المواقع المشمولة في تقرير العنكبوت الليبي. وفي تقرير منفصل، سجّلت Patchstack نحو 420.8 ألف ضمن مؤشر التهديدات المحظورة.

تقيس هذه الأرقام أنشطة مختلفة، لكنها توفر نقطة انطلاق لفهم ما يحدث خلف واجهة الموقع، وكيف تعمل أنظمة الحماية، وما ينبغي لأصحاب المواقع الانتباه إليه.

ماذا تكشف 375 مليون طلب عن حركة المواقع الإلكترونية؟

كل صفحة يفتحها الزائر تولّد نشاطًا يتجاوز عرض محتواها. فتحميل الصور وملفات التنسيق والبرمجيات قد يتطلب إرسال عدة طلبات إلى الخادم. ولهذا، يمكن لزائر واحد يتصفح بضع صفحات أن يولّد عددًا كبيرًا من الطلبات.

وبحسب بيانات Cloudflare، بلغ متوسط النشاط نحو 12.5 مليون طلب يوميًا ضمن نطاق التقرير.

لكن هذا الرقم لا يمثل عدد الزوار الفريدين أو محاولات الهجوم، بل إجمالي الطلبات التي جرت معالجتها.

بالنسبة للشركات، يكمن التحدي في التمييز بين الطلبات التي ينبغي السماح لها بالوصول إلى الموقع، وتلك التي تتطلب فحصًا أو تدخلًا أمنيًا.

فالعميل الذي يفتح صفحة أحد المنتجات يحتاج إلى الوصول إليها دون عوائق، بينما يتطلب الطلب الذي يحاول استغلال ثغرة أمنية في أحد مكونات الموقع استجابة مختلفة.

ولا يكفي حجم حركة المرور وحده لتحديد نسبة النشاط الضار، لكنه يوضح حجم الطلبات التي تعمل أنظمة تصفية الحركة على التعامل معها.

لفهم الصورة الأمنية بصورة أدق، لا بد من النظر إلى ما هو أبعد من إجمالي الطلبات، وفحص الإجراءات الأمنية المتخذة وأسبابها.

97.50% من الطلبات كانت مشفّرة، فماذا يعني ذلك؟

أظهر تقرير Cloudflare أن 97.50% من الطلبات استخدمت اتصالات مشفّرة، أي ما يقارب 366 مليون طلب. كما شكّلت الاتصالات المشفّرة 98.55% من إجمالي البيانات المنقولة.

يساعد التشفير على حماية المعلومات أثناء انتقالها بين الأنظمة، وهو أمر مهم عند إرسال بيانات التواصل، أو تسجيل الدخول، أو مشاركة المعلومات عبر المواقع الإلكترونية.

لكن عندما تعمل Cloudflare وسيطًا بين الزائر وخادم الاستضافة، فهناك اتصالان يجب أخذهما في الاعتبار:

الأول بين الزائر وCloudflare، والثاني بين Cloudflare وخادم الاستضافة.

ولا تعني نسبة التشفير المسجّلة بالضرورة أن الاتصالين محميان بالإعدادات المناسبة.

تحدد إعدادات SSL/TLS في Cloudflare كيفية تأمين الاتصال بالخادم الأصلي (Origin Server)، بينما يضيف وضع Full (strict) التحقق من صلاحية شهادة الخادم وفق متطلبات Cloudflare.

لذلك، فإن السؤال الأهم لأصحاب المواقع ليس مجرد ظهور HTTPS في المتصفح، بل هل جرى التحقق من تأمين الاتصال حتى خادم الاستضافة نفسه؟

ماذا يخبرنا مؤشر التهديدات المحظورة في Patchstack؟

سجّل تقرير Patchstack نحو 420.8 ألف ضمن مؤشر التهديدات المحظورة، وهو الرقم الأكثر ارتباطًا بنشاط الحظر الأمني بين البيانات المعروضة.

لكن من المهم تفسيره بدقة.

فالحدث الذي جرى حظره لا يعني أن الموقع تعرض للاختراق، كما لا يمكن اعتبار الرقم دليلًا على وجود 420,800 مهاجم مختلف أو محاولة اختراق مؤكدة بصورة مستقلة.

تتضح أهمية هذا المؤشر أكثر عند النظر إلى كيفية إدارة المواقع الإلكترونية وصيانتها.

فالموقع المبني باستخدام WordPress قد يعتمد على إضافات متعددة لإدارة نماذج التواصل والحجوزات وعمليات الدفع وغيرها من الوظائف.

وكل إضافة مثبتة تصبح جزءًا من المكونات البرمجية التي تحتاج إلى متابعة وتحديث.

وقد يستمر الموقع في استقبال طلبات العملاء بصورة طبيعية، حتى عندما تحتوي إحدى إضافاته على ثغرة أمنية معروفة.

تساعد Patchstack على اكتشاف الثغرات المعروفة في المكونات المثبتة، وتوفر تصحيحات افتراضية (Virtual Patches) للثغرات المدعومة.

تعمل هذه التصحيحات على المساعدة في منع استغلال الثغرات دون تعديل البرنامج المتأثر مباشرة، لكنها لا تُغني عن معالجة الثغرة في المكوّن نفسه.

بالنسبة للشركات، هذا يعني أن التنبيهات الأمنية تحتاج إلى مسؤول يتابعها. شخص يراجع المشكلة، ويحدد ما إذا كانت الإضافة تحتاج إلى تحديث أو استبدال، ويتأكد من استكمال المعالجة.

استمرار نموذج التواصل في العمل لا يعني بالضرورة أن الإضافة المسؤولة عنه آمنة.

لماذا تحتاج حماية المواقع الإلكترونية إلى أكثر من طبقة أمنية؟

لنفترض أن شركة تعتمد على موقعها الإلكتروني لاستقبال معظم طلبات عروض الأسعار.

حماية هذه الخدمة لا تتوقف عند منع الطلبات الضارة، بل تشمل عدة مسؤوليات:

• فحص حركة المرور الواردة والتعامل مع الطلبات الضارة.
• متابعة الثغرات الأمنية في البرمجيات التي يعمل بها الموقع.
• اكتشاف الملفات الخبيثة داخل بيئة الاستضافة.
• الاحتفاظ بنسخ احتياطية قابلة للاستعادة عند الحاجة.

ولهذا، يقدم العنكبوت الليبي حلولًا أمنية مختلفة، تتكامل أدوارها في بعض الجوانب، لكنها تعالج مستويات مختلفة من المخاطر.

تعمل Cloudflare على مستوى حركة المرور، من خلال أدوات تساعد على فحص الطلبات الواردة والتعامل مع الأنشطة الضارة.

أما Patchstack، فتركز على الثغرات الأمنية المعروفة في التطبيقات، وخصوصًا WordPress وإضافاته ومكوناته.

وتضيف Monarx مستوى آخر من الحماية عبر اكتشاف البرمجيات الخبيثة داخل بيئة الاستضافة، مع إمكانية معالجتها تلقائيًا عند تفعيل ميزة الحماية النشطة (Active Protection).

وهنا يظهر فرق مهم: اكتشاف البرمجيات الخبيثة ومعالجتها تلقائيًا ليسا الوظيفة نفسها.

فقد تتمكن إحدى أدوات الحماية من اكتشاف ملف ضار والإبلاغ عنه، دون أن يعني ذلك بالضرورة إزالته أو عزله تلقائيًا.

لذلك، من المهم أن يعرف صاحب الموقع وظائف الحماية المفعّلة لديه، ومن المسؤول عن الاستجابة للتنبيهات.

السؤال ليس فقط ما إذا كان الموقع يستخدم أدوات أمنية، بل ما إذا كانت هذه الأدوات تغطي المخاطر الفعلية، وما إذا كانت نتائجها تُتابَع وتُعالَج.

أربع خطوات تستحق المراجعة لحماية موقعك

تساعد التقارير الأمنية على فهم ما يحدث، لكن تحويل هذه المعلومات إلى حماية فعلية يتطلب مسؤوليات واضحة.

1. تأكد من المسؤول عن صيانة الموقع

حدد الشخص أو الجهة المسؤولة عن تحديث نظام إدارة المحتوى والإضافات والقوالب والأكواد المخصصة.

ومن المهم الاتفاق على كيفية ترتيب أولويات التحديثات الأمنية، خصوصًا عندما يتوقف أحد المكونات عن تلقي الدعم.

2. راجع وجهة التنبيهات الأمنية

تأكد من وصول التنبيهات إلى شخص يستطيع مراجعتها واتخاذ الإجراءات اللازمة.

فالتنبيه الذي يصل إلى بريد إلكتروني غير مستخدم لن يساعد الشركة على معالجة المشكلة، حتى لو نجح النظام في اكتشافها.

3. راجع صلاحيات الوصول إلى لوحة الإدارة

تحقق من الحسابات التي يمكنها تسجيل الدخول إلى الموقع، واحذف الحسابات التي لم تعد ضرورية.

وفعّل المصادقة متعددة العوامل حيثما كانت متاحة، مع منح كل مستخدم الصلاحيات التي يحتاجها لأداء مهامه فقط.

4. اختبر إمكانية استعادة النسخ الاحتياطية

تأكد من البيانات التي تشملها النسخ الاحتياطية، ومدى حداثتها، وموعد آخر اختبار ناجح لاستعادة الموقع.

وإذا كانت الشركة تستقبل الطلبات أو الاستفسارات عبر موقعها، فينبغي أن تراعي خطة الاستعادة البيانات التي أُنشئت بعد آخر نسخة احتياطية.

تجعل هذه الخطوات إدارة أمن الموقع أكثر وضوحًا، لأن كل خطوة ترتبط بمسؤول محدد وإجراء يمكن متابعته.

القيمة الحقيقية للحماية تظهر فيما يحدث بعد اكتشاف التهديد

توفر أرقام التهديدات المحظورة دليلًا على نشاط أنظمة الحماية، لكنها لا تقدم وحدها صورة كاملة عن مستوى أمان الموقع.

فالمعيار الأهم يرتبط بما يحدث بعد رصد المشكلة.

هل تُعالَج الثغرات الأمنية؟ هل تخضع التنبيهات للمراجعة؟ هل صلاحيات الإدارة مضبوطة؟ وهل يمكن استعادة الموقع عند الحاجة؟

بالنسبة للشركات التي تعتمد على مواقعها لاستقبال الاستفسارات وخدمة العملاء ومعالجة الطلبات، تؤثر الإجابات عن هذه الأسئلة في قدرتها على استمرار تقديم خدماتها.

هل تعرف ما الذي تغطيه أنظمة الحماية في موقعك حاليًا؟

تواصل مع فريق العنكبوت الليبي لمراجعة إعدادات الحماية لديك، وتحديد الجوانب التي قد تحتاج إلى تحسين، ومناقشة الحلول الأمنية المناسبة لموقعك وبيئة استضافتك.

ناقش احتياجات حماية موقعك مع فريقنا.