خلال الأسبوع الأخير سجّل نظام المراقبة الأمنية لدينا مئات المحاولات للوصول إلى موقعنا. الرقم يبدو مقلقًا، لكن الواقع أكثر هدوءًا بكثير، وهذا المقال سيشرح السبب.
لم تحدث أي هجمات حقيقية. تبيّن أن جميع الأحداث الأمنية الخارجية البالغ عددها 616، والتي سُجّلت من 7 إلى 15 يوليو، كانت مجرد ضجيج صادر عن روبوتات آلية، وهي ماسحات تفحص آلاف المواقع دفعة واحدة بحثًا عن ثغرات WordPress المعروفة. موقعنا غير مبني على WordPress، لذلك لم تكن المسارات المطلوبة موجودة أصلًا، وانتهت كل محاولة بالحظر أو بخطأ 404.
الأرقام
ما الذي تم البحث عنه تحديدًا، ولماذا يُعد خطيرًا على الموقع غير المحمي
المسارات التالية أهداف كلاسيكية لـ WordPress. في حالتنا كانت غير ضارة لأن هذه الملفات غير موجودة أصلًا، لكن من المفيد أن نفهم لماذا يتم البحث عن هذه المسارات تحديدًا.
/wp-login.php – 273 طلبًا، 197 عنوان IP فريدًا هذا هو نموذج تسجيل الدخول إلى لوحة إدارة WordPress. تحاول الروبوتات تنفيذ هجمات القوة الغاشمة (brute force)، أي تجرّب تلقائيًا آلاف التركيبات من أسماء المستخدمين وكلمات المرور على أمل تخمين بيانات دخول صالحة. وإذا كانت كلمات المرور في الموقع ضعيفة أو لا يوجد حد لمحاولات تسجيل الدخول، فقد ينتهي هذا الهجوم بالحصول على صلاحيات المسؤول الكاملة.
/xmlrpc.php – 255 طلبًا، 183 عنوان IP فريدًا ملف واجهة قديم في WordPress يُستخدم للنشر عن بُعد. وهو هدف شائع للهجمات لسببين: يمكن استخدامه لتخمين كلمات المرور بسرعة أكبر بكثير من نموذج تسجيل الدخول العادي (مئات التركيبات في طلب واحد)، كما يمكن إساءة استخدامه في هجمات تضخيم DDoS ضد أطراف ثالثة عبر وظيفة “pingback”.
/en/wp-json/wp/v2/users/me – 23 طلبًا، 21 عنوان IP فريدًا نقطة نهاية في WordPress REST API قد تكشف افتراضيًا أسماء مستخدمين صالحة. هذا بحد ذاته ليس هجومًا، لكنه خطوة استطلاع، فبعد معرفة أسماء المستخدمين الحقيقية يستطيع المهاجم توجيه محاولات القوة الغاشمة اللاحقة بدقة أكبر.
/.env – 14 طلبًا، 12 عنوان IP فريدًا هذا هو الهدف الوحيد في قائمتنا الذي كان يحمل احتمال ضرر حقيقي. تحتوي ملفات .env عادةً على كلمات مرور قواعد البيانات ومفاتيح API وأسرار أخرى. وإذا كان هذا الملف متاحًا من الخارج (بسبب إعدادات خادم خاطئة)، فقد يعني تسرّب محتواه اختراقًا كاملًا للنظام، ليس للموقع فحسب بل للخدمات المرتبطة به أيضًا. في حالتنا لا يقدّم Next.js هذا الملف للعامة، لذلك انتهت جميع المحاولات بخطأ 404 أو بالحظر.
/lv/wp-content/uploads – 7 طلبات، 7 عناوين IP فريدة مجلد رفع الملفات في WordPress. إذا كان مُعدًّا بشكل خاطئ (مثلًا يسمح بتنفيذ ملفات PHP)، يمكن للمهاجم الذي حصل ولو على وصول بسيط أن يرفع سكربتًا خبيثًا ويستولي على التحكم الكامل بالخادم.
كيف يعمل نظام المراقبة الأمنية لدينا
لا تأتي هذه البيانات من سجلات الخادم العادية، بل يحلّلها نظام أمني بالذكاء الاصطناعي طوّرناه بأنفسنا، يتابع كل حركة المرور الواردة، ويصنّف كل حدث حسب درجة خطورته، ويتخذ قرار الحظر في الوقت الفعلي. النظام متصل بقناة إشعارات على Discord، حيث يُنشر مرتين يوميًا تقرير موجز: كم حدثًا وقع، وكم منها تم حظره، وهل هناك ما يستدعي الانتباه.
إضافةً إلى التقارير الدورية، يملك النظام ما يُعرف بآلية page call – وهي إشعار مباشر وعاجل لفريق التطوير يتجاوز الملخص المعتاد مرتين يوميًا وينبّه فورًا عند حدوث أمر يتطلب ردّ فعل فوريًا. وعلى عكس سجل الضجيج المعتاد (حيث تُسجَّل مئات طلبات الروبوتات وتُحظر بصمت)، فإن page call مخصص للحالات النادرة والمهمة فعلًا.
عمليًا يبدو page call هكذا: يصل إلى الهاتف اتصال مباشر وعاجل يُبلغ بما حدث. لا يمكن تأجيل هذا الاتصال (snooze)، ولإيقافه يجب النهوض والدخول إلى النظام. وبمجرد أن يتصل أحد أفراد الفريق، يُلغى page call ويعرض النظام من تولّى معالجة الحادث بالتحديد. وعند حلّ المشكلة، يفحص النظام تلقائيًا قبل الإطلاق الكود والأخطاء والثغرات، أولًا قبل وصوله إلى مستودع GitHub الخاص بنا، ثم إلى الخادم، وأخيرًا إلى الموقع المباشر (live)، للتأكد من وجود نسخة موحّدة ومصحّحة في كل مكان.
في الفترة الأخيرة عملت هذه الآلية مرتين:
- محاولة الوصول إلى ملف
.env– بما أن هذا الملف قد يحتوي على كلمات مرور قواعد البيانات ومفاتيح API، صنّفه النظام كحدث عالي الخطورة ونبّه الفريق فورًا، رغم أن الطلب تم حظره تلقائيًا. - gramatika.evoex.eu عدم التوفر – عندما أصبح موقع هذا النطاق الفرعي غير قابل للوصول، تعرّف النظام على ذلك كانقطاع في الخدمة (وليس حادثًا أمنيًا) وأبلغ الفريق فورًا ليتمكن من التحرك بسرعة واستعادة الخدمة.
يتيح هذا النهج ثنائي المستويات – تسجيل صامت لضجيج الروبوتات الجماعي، وإشعار فوري في الحالات النادرة المهمة فعلًا – لفريق التطوير ألا ينشغل بمئات محاولات المسح غير الضارة، ومن دون أن يمرّ أي حدث مهم حقًا دون ملاحظة حتى موعد المراجعة المقبل.
المصدر
جاء معظم الزيارات من الولايات المتحدة (157)، وفرنسا (52)، وبريطانيا (48)، وفيتنام (46)، وألمانيا (39)، وسنغافورة (36)، والهند (32). وكانت سلاسل User-Agent مزوّرة لتبدو كمتصفحات عادية، وهي علامة نموذجية لشبكة بوتات تحاول أن تبدو كزائر حقيقي.
الاتجاه تنازلي بوضوح
عدد الأحداث حسب الأيام (من 07-07 إلى 07-15): 148 → 137 → 75 → 61 → 110 → 41 → 38 → 13 → 1.
يتزامن هذا الانخفاض مع الحظر الدائم لـ 95 عنوان IP – فالحماية تعمل تمامًا كما هو مخطط لها.
الخلاصة
لم يحدث أي هجوم ناجح، ولا تسريب للبيانات، ولا رسائل مزعجة عبر النماذج، ولا حالات فشل في المصادقة. كانت جميع المحاولات عبارة عن ماسحات WordPress آلية تبحث عن أهداف غير موجودة هنا. وهذا لا يعني أن الأمان زائد عن الحاجة – بل على العكس، إنه يثبت أن بنية مضبوطة بشكل صحيح وغير قائمة على WordPress، مع حظر نشط لعناوين IP، تصدّ بفعالية حتى الهجمات الآلية الجماعية قبل أن تصل إلى أي شيء ذي قيمة.