6.1 KiB
6.1 KiB
خطة الاستجابة للحوادث - Incident Response Plan
نوع الحادثة
هجوم Brute Force ناجح على API Login أدى إلى تسريب بيانات
المرحلة 1: الاحتواء (Containment) - أول 30 دقيقة
الإجراءات الفورية:
# 1. إلغاء جميع الـ JWT tokens النشطة
# في قاعدة البيانات أو Redis
redis-cli FLUSHDB # إذا كانت sessions في Redis
# أو عبر API إداري
curl -X POST https://app.ghaymah.systems/api/admin/invalidate-all-tokens \
-H "Authorization: Bearer $ADMIN_TOKEN"
# 2. حظر IP المهاجم
# في iptables
sudo iptables -A INPUT -s 192.168.1.100 -j DROP
# أو في nginx
echo "deny 192.168.1.100;" >> /etc/nginx/conf.d/blocked-ips.conf
sudo nginx -s reload
# 3. تعطيل الحساب المخترق
UPDATE users SET status = 'suspended',
password_hash = 'COMPROMISED_RESET_REQUIRED'
WHERE username = 'admin';
قائمة التحقق:
- إلغاء جميع الـ tokens
- حظر IP المهاجم
- تعطيل الحساب المخترق
- إبلاغ فريق الأمن
- توثيق وقت الاكتشاف
المرحلة 2: التحقيق (Investigation) - 1-4 ساعات
جمع الأدلة:
# 1. حفظ الـ logs
cp /var/log/nginx/access.log /incident/access.log.$(date +%Y%m%d)
cp /var/log/nginx/error.log /incident/error.log.$(date +%Y%m%d)
# 2. تحليل الطلبات المشبوهة
grep "POST /api/login" /var/log/nginx/access.log | \
awk '{print $1}' | sort | uniq -c | sort -rn | head -20
# 3. تتبع نشاط المهاجم بعد الدخول
grep "192.168.1.100" /var/log/nginx/access.log | \
grep -E "200|201" > /incident/attacker-activity.log
# 4. تحديد البيانات المسربة
grep "192.168.1.100" /var/log/nginx/access.log | \
grep -E "/api/users|/api/export"
الأسئلة المطلوب الإجابة عليها:
- متى بدأ الهجوم؟
- كم محاولة تمت قبل النجاح؟
- ما البيانات التي تم الوصول إليها؟
- هل يوجد backdoors؟
- هل تأثرت أنظمة أخرى؟
المرحلة 3: الاستئصال (Eradication) - 4-8 ساعات
الإجراءات:
# 1. إعادة تعيين كلمات مرور جميع المستخدمين
# إرسال بريد إلكتروني لجميع المستخدمين
# 2. فحص النظام من backdoors
# فحص cron jobs
crontab -l
cat /etc/crontab
# فحص authorized_keys
cat ~/.ssh/authorized_keys
# فحص الملفات المعدلة مؤخراً
find /app -mtime -1 -type f
# 3. تحديث التبعيات
npm audit fix
# أو
pip install --upgrade -r requirements.txt
قائمة التحقق:
- إعادة تعيين كلمات المرور
- فحص backdoors
- مراجعة صلاحيات المستخدمين
- تحديث التبعيات الأمنية
المرحلة 4: الاستعادة (Recovery) - 8-24 ساعة
خطوات الاستعادة:
- تفعيل الحماية الجديدة:
// إضافة Rate Limiting
const rateLimit = require('express-rate-limit');
app.use('/api/login', rateLimit({
windowMs: 15 * 60 * 1000,
max: 5,
message: 'محاولات كثيرة، حاول لاحقاً'
}));
- تفعيل Account Lockout:
// قفل الحساب بعد 5 محاولات فاشلة
if (failedAttempts >= 5) {
await lockAccount(userId, 30 * 60 * 1000); // 30 دقيقة
}
- إعادة تشغيل الخدمات:
# إعادة نشر التطبيق على غيمة
git push origin main # النشر التلقائي
قائمة التحقق:
- تفعيل Rate Limiting
- تفعيل Account Lockout
- إضافة CAPTCHA
- تفعيل MFA للحسابات الإدارية
- إعادة تشغيل الخدمات
- اختبار الحماية الجديدة
المرحلة 5: إبلاغ المتأثرين - 24-48 ساعة
نموذج البريد الإلكتروني:
الموضوع: إشعار أمني مهم - [اسم التطبيق]
عزيزي المستخدم،
نود إبلاغك بحادثة أمنية وقعت بتاريخ [التاريخ].
تم الوصول غير المصرح به إلى بعض بيانات المستخدمين.
البيانات المتأثرة:
- الاسم
- البريد الإلكتروني
- [أي بيانات أخرى]
الإجراءات المتخذة:
1. تم إيقاف الهجوم فوراً
2. تم تعزيز الحماية
3. تم إعادة تعيين جميع كلمات المرور
ما يجب عليك فعله:
1. تغيير كلمة المرور فوراً
2. تفعيل المصادقة الثنائية
3. مراقبة حساباتك الأخرى
نعتذر عن أي إزعاج.
فريق الأمن
المرحلة 6: الدروس المستفادة - أسبوع
اجتماع Post-Mortem:
| السؤال | الإجابة |
|---|---|
| ما الذي حدث؟ | هجوم brute force ناجح |
| لماذا حدث؟ | عدم وجود rate limiting + كلمة مرور ضعيفة |
| كيف اكتشفناه؟ | مراجعة يدوية للـ logs |
| كم استغرق الاحتواء؟ | [X] دقيقة |
| ما الذي يجب تحسينه؟ | إضافة تنبيهات تلقائية |
التحسينات المطلوبة:
- تفعيل Rate Limiting على جميع APIs
- فرض سياسة كلمات مرور قوية
- تفعيل MFA إلزامياً للإداريين
- إضافة تنبيهات للنشاط المشبوه
- تدريب الفريق على الاستجابة للحوادث
جهات الاتصال
| الدور | الاسم | الهاتف | البريد |
|---|---|---|---|
| قائد الحادثة | [الاسم] | [الرقم] | [البريد] |
| فريق DevOps | [الاسم] | [الرقم] | [البريد] |
| المستشار القانوني | [الاسم] | [الرقم] | [البريد] |
| دعم غيمة | - | - | support@ghaymah.systems |