محاولات دخول كثيرة على ووردبريس: تجربة حماية بدون اثقال الموقع
سجل الحماية مليان محاولات دخول، وخايف تعمل اختبار يزيد الحمل او يقفلك برا الموقع؟ ما بدك الاف الطلبات حتى تثبت ان تحديد المعدل شغال. عملنا سبعة طلبات فقط على حساب تجريبي: ثلاث محاولات قبل الحماية، واربع بعدها. المحاولة الرابعة فقط انتقلت لرسالة انتظار، وبعد تنظيف العداد نجح الدخول الصحيح.
إضافة المختبر استخدمت خطاف wp_login_failed الرسمي لعد الفشل وخطاف authenticate لوقف المحاولة بعد ثلاث مرات لمدة خمس دقائق. المفتاح جمع حساب الاختبار وعنوان المصدر بعد تحويلهما لبصمة، وما سجل كلمة المرور.
الموضوع متكرر في نقاش ريديت عن سيل محاولات الدخول وفي دعم ووردبريس عن الحدود والنتائج الكاذبة. راجع كمان توثيق wp_login_failed وauthenticate.
نتيجة التجربة
- قبل الحماية: 3 محاولات خاطئة، ولا حظر.
- مع الحماية: اول 3 سجلت فشلا، والرابعة عرضت رسالة انتظار.
- كل الردود بقيت HTTP 200 لان صفحة الدخول تعرض الخطأ داخلها.
- وسيط زمن الطلب كان 2426 مللي ثانية قبلها و2063 معها في جهاز المختبر؛ ما ظهر تاخير اضافي من العداد.
- بعد تعطيل القاعدة ومسح العداد، كلمة المرور الصحيحة نجحت.
قبل تحديد المعدل
استخدمنا حساب اختبار وكلمات مرور خاطئة مولدة للتجربة. ما جربنا اسم المدير الحقيقي وما عملنا قائمة اسماء. هذا كافي لتوثيق السلوك من غير توليد ضغط او بيانات مزعجة.
المحاولة الرابعة توقفت
حطينا الفلتر بعد التحقق الاساسي حتى ما تستبدله مرشحات المصادقة الافتراضية. هاي نقطة اكتشفناها بالتجربة: في المحاولة الاولى للبرمجة كان الفلتر مبكرا وانكتب فوق خطئه، فعدلنا الاولوية واعدنا القياس حتى ظهر الحظر الفعلي.
التنظيف وفحص الدخول الصحيح
فيديو توثيق التجربة الفعلية
هذا تسجيل شاشة صامت ومتواصل للاختبار وهو يحدث داخل بيئة محلية معزولة. تظهر الخطوات والنتائج الفعلية لحظة التنفيذ، من غير تركيب صور ثابتة.
وين تعمل الحماية؟
العداد داخل ووردبريس مفيد، لكنه يشغل PHP وقاعدة البيانات قبل ما يرفض الطلب. اذا عندك حجم كبير، اعمل الطبقة الاولى في CDN او WAF او خادم الويب، وبعدها خلي ووردبريس يسجل الحالات المهمة. هيك الطلب المزعج ينوقف ارخص.
لا تعتمد على IP لحاله
مستخدمون كثير ممكن يطلعوا من نفس IP، والمهاجم يقدر يغير IP. استخدم مفتاحا موزونا يجمع المصدر والحساب والمسار، وحدودا قصيرة ثم تصعيد تدريجي. وفر طريقة امنة لفك القفل للمدير وما تعمل حظر دائم من محاولة بسيطة.
رسالة الخطأ
لا تكتب الحساب موجود لكن كلمة المرور غلط. استخدم رسالة محايدة. وحتى رسالة تحديد المعدل لازم ما تكشف معلومات اكثر من اللازم. سجل التفاصيل داخليا مع الوقت والمصدر والبصمة، واعرض للزائر تعليمات عامة.
2FA اهم من تغيير رابط الدخول
تغيير wp-login يقلل ضجيج البوتات البسيطة، لكنه مش بديل عن كلمة مرور قوية و2FA وتحديد معدل. بعض التكاملات وتطبيقات الهاتف ومسار XML-RPC ما بتتبع الرابط الجديد. اختبر كل طرق المصادقة المستخدمة قبل اعتماد تغيير المسار.
خطة بدون اثقال الموقع
- راجع سجلا موجودا بدل توليد هجوم.
- انشئ حساب اختبار بلا محتوى ولا صلاحيات مدير.
- حدد 3 او 4 طلبات فقط في نافذة قصيرة.
- قارن الاستجابة قبل الحماية وعند الحد.
- جرب كلمة المرور الصحيحة بعد انتهاء او مسح القفل.
- راقب CPU وPHP workers وقاعدة البيانات وقت الاختبار.
- احذف الحساب والعداد بعد التوثيق.
شو تراقب في السجل؟
- الوقت والمسار ونتيجة المصادقة.
- بصمة IP بعد تقليل دقته اذا ما تحتاج العنوان الكامل.
- وكيل المستخدم وحالة WAF.
- نجاح مفاجئ بعد سلسلة فشل.
- حسابات ادارية جديدة او تغيير بريد مدير.
- طلبات XML-RPC وREST المرتبطة بالمصادقة.
متى تكون المحاولات اختراقا ناجحا؟
الفشل وحده ما يعني ان الموقع اخترق. الاشارات الاخطر: دخول ناجح غير معروف، مدير جديد، ملف إضافة تغير، مهمة Cron غريبة، تحويل زوار، او مفاتيح API جديدة. وقتها لا تكتفي بحظر IP؛ تعامل معها كحادث وافحص الموقع والنسخ والسجلات.
حدود تجربتنا
الاختبار يقيس منطق الحد داخل نسخة محلية، مش قدرة Cloudflare او الخادم على صد شبكة موزعة. الازمنة تشمل جهاز Windows وخادم PHP التطويري، لذلك ما نعممها على الاستضافة. القيمة هنا هي اثبات السلوك بعدد صغير وتنظيف القفل.
الخلاصة
ثلاث محاولات خاطئة كانت كافية لملء العداد، والرابعة توقفت برسالة محايدة. ما احتجنا ضغطا ولا الاف الطلبات. بعد تعطيل القاعدة ومسح العداد نجح الدخول الصحيح، وهذا فحص ضروري حتى ما تتحول الحماية لقفل على صاحب الموقع.
