أنا مسير موقع شركة صغير. أول مرة أراجع السجلات (logs) بشكل جدي وصدمني اللي شفته.
في آلاف الطلبات يومياً على عناوين مثل /wp-admin، /.env، /phpmyadmin، /.git/config. مع إننا ما نستخدم ووردبريس أصلاً.
هل هذا هجوم موجه ضدنا، ولا كل المواقع تصير عندها هيك؟ شو لازم أعمل؟
أولاً اطمئن: هذا مش هجوم موجه ضدك، هو مجرد ضجيج خلفي (background noise) تستقبله أي عنوان متصل بالإنترنت. المتصفحات الآلية تفحص كل نطاقات IP باستمرار وتجرب العناوين المعروفة بالثغرات. هم ما يعرفون موقعك إيش، ولا يهتمون أصلاً.
خليني أكون شاكياً شوي، لأن قول "طبيعي" ما يعني "غير مهم". لازم تفرق بين هالنقطتين:
الضجيج الآلي: طلبات على عناوين عشوائية وترجع 404، من IPs مختلفة، بأنماط متكررة. هاي مجرد ضجيج.
اللي لازم تنتبه له: المحاولات على عناوينك الموجودة فعلاً. تجارب كلمات مرور متتالية على صفحة الدخول، محاولات وصول للوحة التحكم، تلاعب بالمعاملات (parameters). هذا معناه إن في حدا فعلاً فحص موقعك.
اللي لازم تسويه، حسب الأهمية: لا تترك لوحة التحكم مفتوحة للجميع، حط حد لمعدل محاولات الدخول (rate limiting)، خلي برامجك محدثة، وخلي عندك نسخة احتياطية واختبرها بالتحميل فعلياً.
آخر نقطة هي اللي الكل ينساها. النسخة الاحتياطية اللي ما اختبرتها، ما تعتبر نسخة احتياطية.
خليني أضيف نقطة تقنية من منظور مركز العمليات الأمنية (SOC).
محاولة منع هذا الضجيج كلياً (مثل وضع كل IP في قائمة الحظر) غالباً جهد ضائع. الـ IPs تتغير باستمرار، القائمة تكبر، ويوم من الأيام تحظر مستخدمك أنت بالغلط.
بدل كذا، صفّي الضجيج عشان تشوف الحدث الحقيقي. طريقة عملية: اكتب طلبات الـ 404 في قناة منفصلة، وخلّي التدفق الرئيسي للسجلات يعرض فقط طلبات الـ 200 والـ 500. وكمان خلي عداد منفصل لمحاولات الدخول الفاشلة.
كنقطة تنبيه، أنصحك بالتالي: عدد كبير من محاولات الدخول الفاشلة من مصدر واحد خلال وقت قصير. هذا هو النمط اللي ينفصل فعلاً عن الضجيج ويحتاج تدخل.
وكمان لا تنسى: أكثر الحوادث الحقيقية شيوعاً ما تبدأ باختراق خارجي بالقوة، بل بدخول باستخدام كلمة مرور مسربة. لذلك، فتح التحقق بخطوتين (2FA) مهم مثل مراجعة السجلات.
خليني أسأل سؤال: قلت إنك أول مرة تراجع هذه السجلات بشكل جدي. طيب، لحد وين تقدر ترجع بالزمن قبل كذا؟
سبب السؤال: في أغلب السيرفرات، مدة حفظ السجلات الافتراضية قصيرة. أي حدا يريد يرجع بالزمن عند حدوث مشكلة يصطدم بنفس الجدار: ما في سجلات.
كنصيحة عملية لمن يبحث عن أدلة: تأكد من مدة حفظ السجلات وارفعها لـ 90 يوم على الأقل. تكلفة التخزين بسيطة، لكن قيمتها وقت الحادثة كبيرة جداً. وكمان، لا تخزن السجلات على السيرفر نفسه فقط، احتفظ بنسخة في مكان آخر؛ لو تم اختراق السيرفر، أول شي يتم حذفه هو السجلات.
خليني أعطيك أرقام من منظور الاستضافة، مش تخمين، هذا النمط اللي نشوفه بانتظام من لوحة التحكم عندنا.
حتى اسم النطاق الجديد، اللي ما تم الترويج له ولا يوجد له أي روابط في أي مكان، يبدأ باستقبال هذه المحاولات الآلية خلال الأسبوع الأول. السبب بسيط: سجلات شفافية الشهادات (Certificate Transparency logs) عامة، ويمكن رؤية أسماء النطاقات الجديدة من خلالها.
يعني ما في حالة أمنية اسمها "موقعي صغير وما حدا يعرفه". الصغر ما يخليك غير مرئي، بس يقلل احتمال الهجمات الموجهة.
أنا طالب، وبدي أسأل سؤال، إذا كان السؤال غبي سامحوني.
ليه المتصفحات دي بتدور على ملف /.env؟ يعني إيه اللي جواه اللي يخليه غالي كده؟
مش غريب خالص، دي سؤال في محله تماماً.
ملف .env هو ملف نصي بيحفظ إعدادات التطبيق (environment، يعني متغيرات البيئة). عادةً بيكون فيه عنوان وقاعدة بيانات كلمة السر، ومفاتيح خدمات الطرف الثالث، ومفتاح تشفير الجلسات.
يعني بالنسبة للمهاجم، الملف ده معناه إنه يلاقي المفتاح بدل ما يكسر الباب. عشان كده المتصفحات بتجرب الأول عليه؛ تكلفته طلب واحد، وعائده كل حاجة.
عادةً المفروض الملف ده يكون بره المجلد اللي سيرفر الويب بيخدم منه. لو الإعداد غلط، بيفضل جوه مجلد public وبيبقى مقروء من المتصفح. نفس المنطق ينطبق على /.git/config: لو مخزن المشروع اتنشر بالغلط، الكود المصدري كله بيتنزل.
التحقق سهل جداً: اكتب /.env بعد عنوان موقعك وجرب. لو طلع 404 مفيش مشكلة، لو شفت المحتوى اقفلوه فوراً وغير كل المفاتيح اللي في الملف. القفل مش كفاية، المفروض نفترض إن البيانات اتسربت.
خلونا نضيف ملاحظة من فريق Doki، لأن العنوان ده لخص موضوع بيتسأل كتير بشكل ممتاز.
إحنا كمان بنشوف الصورة اللي اتشرحت فوق: أي أصل متصل بالإنترنت بيتعمله مسح حتى لو مش معلن. عشان كده بننصح عملائنا أولاً بإعداد جرد للأصول — أي نطاقات، أي نطاقات فرعية، أي سيرفرات هي فعلاً بتاعتنا وأيها لسه شغال ومتنسي.
عملياً، أكتر باب مفتوح بنقابله هو بيئات الاختبار المنسية. النظام الحي بيكون محمي كويس، لكن سيرفر تجريبي اتفتح من سنتين لسه متصل بنفس قاعدة البيانات.
المشاركات هنا للمعلومات العامة؛ بننصحكم بإجراء تقييم محدد النطاق لنظامكم الخاص.
عند النظر إلى العملية ككل، تتغير الصورة. إذا كان التحقق بخطوتين مفعلًا، فإن كلمة المرور المسروقة وحدها لا تكفي.
إذا كان التحقق بخطوتين مفعلًا، فإن كلمة المرور المسروقة وحدها لا تكفي. إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.
أتفق، بل أود التأكيد على هذه النقطة. إذا كانت قناة الإشعارات طويلة، فلن تصل الإشعارات؛ والإشعار غير الواصل يعني حدثًا يُكتشف متأخرًا.
إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.
ملخص سريع للجدد: كلما كان التراجع عن القرار أصعب، كان يجب اتخاذه ببطء أكبر.
كل بند غير مكتوب هو بند سيتذكره الطرفان بشكل مختلف لاحقًا. بالتوفيق.
شكراً لكتابة هذا، فهو صحيح تماماً. إذا لم يكن الإذن والنطاق مكتوبين، فلا تبدأوا الاختبار.
هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.
قضيت وقتًا طويلاً في هذا المجال. معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة.
الخطأ المرتكب من جانب سجل قابل للإصلاح عادةً، لكنه مكلف. أتمنى أن يفيدك هذا.
وكيف حللتم هذه النقطة؟ محاولة فعل هذا بمفردك هي أغلى الطرق.
الخطأ المرتكب من جانب سجل قابل للإصلاح عادةً، لكنه مكلف. هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.