- بواسطة x32x01 ||
فيه حد عمل penetration test لموقع ولقي ملف اسمه passwords.txt فيه حسابات وباسوردات جاهزة. الموضوع ده منتشر وفيه نقطتين مهمين هنكلم عنهم:
لو شغلك ليه علاقة بالسيرفرات، Apache/Nginx، أو APIs - البوست ده هيخلّيك تشوف الحكاية من زاوية عملية وتعرف تحمي نفسك.
ليه بيلاقوا ملفات زي passwords.txt؟
في الحقيقة في سببين رئيسيين:
أمثلة على الملفات اللي بتظهر في الـ access_log وتعتبر خطيرة
الهجمات دي عادةً عشوائية - يعني إيه؟
العديد من البوتات والماسحات بتدور على مسارات ومعروفة:
لا تلصقوا الفشل على الـ AI - ده ظلم!
فيه ناس بتقول: "AI عمل الملف ده" أو "الموديل انتج الكلام ده" - الكلام ده في الغالب مش صح. نموذج ذكاء اصطناعي مش هينتج ملف بأسماء حسابات حقيقية غلط كده لو مش مدخوله بياناتها. اللي حصل فعلاً هو إن في إهمال بشري أو ثغرة/تحميل ملفات قديمة على السيرفر.
ازاي تكشف الحاجات دي في الـ logs؟
لو بتتابع الـ
لو لقيت طلبات كتير لـ .env أو passwords.txt يبقى عندك مشكلة محتاجة فحص فوري.
خطوات عملية تمنع المشكلة من الأساس
لو لقيت passwords.txt - تعمل إيه فورًا؟
مثال عملي: سكربت بسيط يفحص وجود ملفات حساسة
ده مثال بلغة Bash يفحص لو ملفات زي
شغّل السكربت ده دوريًا أو ضيفه في Cron وابعته notifications.
نصيحة أخيرة للمطورين وAdmins
الخلاصة - الكلام في سطر واحد
وجود ملف زي passwords.txt على السيرفر نتيجة إهمال أو اختراق سابق، وده مشكلة إدارية/تقنية مش خطأ من الـ AI. نظم الـ deployment، استخدم أدوات إدارة الأسرار، واعمل فحص دوري للـ logs والملفات - وده هيقلّلك مشاكل كتير قدام. 
- الهجمات العشوائية اللي بتدور على ملفات جاهزة.
- "الشماعة" الجديدة: تحميل المسؤولية على AI غلط.
لو شغلك ليه علاقة بالسيرفرات، Apache/Nginx، أو APIs - البوست ده هيخلّيك تشوف الحكاية من زاوية عملية وتعرف تحمي نفسك.
ليه بيلاقوا ملفات زي passwords.txt؟
في الحقيقة في سببين رئيسيين:1. ملفات مخترقين سابقة متسابَة على السيرفر
يا دوب لو حد اخترق في مرة قبل كده وساب ملفات، الهاكر الجاي ممكن يلاقيها وياخد عليها على الجاهز. الملفات دي ممكن تبقى اسامي مستخدمين، كلمات سر، أو سكربتات جاهزة.2. مطورين/مهندسين شغالين "بلدي" - بياخدوا Backup على السيرفر
لو واحد عمل Backups على السيرفر باسم app.zip أو backup.tar.gz من غير ما يحط نسخه في Git أو repo آمن، فانت كده بتدي للهاكر نسخة من كود المشروع ببلاش. بعض المواقع أصلاً لسه محتاجة Landing page والدومين جديد - وده معناه إن النظام موبنظم من البداية.أمثلة على الملفات اللي بتظهر في الـ access_log وتعتبر خطيرة
- .env ، .env.dev
- .git/ أو ملفات config اللي مسموح وصولها
upload.php,alpha.php,cgi/alpha.cgi- passwords.txt اللي فيها قوائم حسابات جاهزة
الهجمات دي عادةً عشوائية - يعني إيه؟
العديد من البوتات والماسحات بتدور على مسارات ومعروفة:- بتحاول تزور
admin,/wp-login.php,/.env - بتبحث على ملفات احتياطيه مثل
backup.zip - لو لقت أي ملف حساس بتستغله فورًا أو بتنزله للفاترة الجاية
لا تلصقوا الفشل على الـ AI - ده ظلم! 
فيه ناس بتقول: "AI عمل الملف ده" أو "الموديل انتج الكلام ده" - الكلام ده في الغالب مش صح. نموذج ذكاء اصطناعي مش هينتج ملف بأسماء حسابات حقيقية غلط كده لو مش مدخوله بياناتها. اللي حصل فعلاً هو إن في إهمال بشري أو ثغرة/تحميل ملفات قديمة على السيرفر.خلاصة سريعة:
- AI بريء من أخطاء زي وجود
passwords.txtعلى السيرفر. - الخلل غالبًا بشري أو نتيجة إهمال في الـ DevOps / Deployment.
ازاي تكشف الحاجات دي في الـ logs؟
لو بتتابع الـ access_log على Apache أو Nginx هتلاقي محاولات على مسارات مش موجودة أو طلبات لتحميل ملفات غريبة. مثال بسيط للـ access_log entry: NGINX:
192.0.2.10 - - [04/Nov/2025:12:34:56 +0200] "GET /.env HTTP/1.1" 200 612 "-" "Mozilla/5.0" خطوات عملية تمنع المشكلة من الأساس
- أبداً ما تخلي ملفات حساسة قابلة للتحميل: امنع الوصول للـ .env وملفات الـ config من خلال إعدادات الخادم.
NGINX:
# مثال Nginx - منع وصول .env
location ~ /\.env {
deny all;
return 404;
} - خلي الـ Backups برا السيرفر: استخدم Repo آمن (Git + private repo) أو service للسحابة، واحتفظ بالتواريخ والهستوري بتاع التغييرات.
- افحص السيرفر بانتظام: شغّل SCA/IDS وماسحات دورية بتكشف ملفات مش من المفروض تكون موجودة.
- سجّل كل حاجة (Logging + Monitoring): لو في أي تحميل لملف حساس، يترسل لك Alert فورًا.
- Access Controls وPermissions مظبوطة: الملفات الحساسة لها Owner ومجموعات محددة وصلاحيات محدودة.
- Use .gitignore وركز في CI/CD: ما ترفعش ملفات حساسة على الريبو حتى عن طريق الخطأ.
لو لقيت passwords.txt - تعمل إيه فورًا؟
- عزل السيرفر (isolate) أو فصل الخدمة لو الشك كبير.
- خليك منسق مع الـ Incident Response: خذ snapshot من الـ disk واحتفظ بالـ logs.
- غير كل كلمات السر المشتبه فيها فورًا.
- افحص إذا فيه ملفات إضافية أو backdoors.
- راجع نقاط الضعف اللي سببت وجود الملف (permission, backups, deploy process).
- لو محتاج، بلّغ الجهات المسؤولة أو الـ SOC.
مثال عملي: سكربت بسيط يفحص وجود ملفات حساسة
ده مثال بلغة Bash يفحص لو ملفات زي .env أو passwords.txt موجودين في الـ webroot: Bash:
#!/bin/bash
WEBROOT="/var/www/html"
FILES=(".env" "passwords.txt" "backup.zip" ".git")
for f in "${FILES[@]}"; do
if [ -e "$WEBROOT/$f" ]; then
echo "WARNING: $f exists in $WEBROOT"
fi
done نصيحة أخيرة للمطورين وAdmins
- نظم الـ Deployment وادخل الـ Secrets في Vault (مثل HashiCorp Vault أو AWS Secrets Manager).
- ماتعملش Backups على نفس السيرفر.
- اتعلم تعمل
gitصح وما ترفعش ملفات حساسة على الريبو. - وافتكر: لو حصلت مشكلة، الحل مش لوم الـAI - الحل تحليل السبب الجذري وإصلاح العملية.