ghaymah-exam-Mohammad-Shehadeh-SecOps/q4-siem-log-analysis

نظام SIEM مبسط — دليل التسليم

المحتويات

الملف	الوظيفة
siem_analyzer.py	المحرك الرئيسي: يقرأ 3 مصادر سجلات، يكتشف الأنماط المشبوهة، يكتب output/alerts.json
generate_sample_logs.py	يولّد سجلات تجريبية (Web/Auth/Firewall) لتجربة النظام قبل التسليم
dashboard.html	لوحة المراقبة (HTML/CSS/JS) — تعرض التنبيهات وعناوين IP المشبوهة
logs/	مجلد السجلات الخام (المدخلات)
output/alerts.json	مخرجات التحليل (المخرج الذي تقرأه اللوحة)

---

1) المصادر الثلاثة المُختارة ولماذا

#	المصدر	الطبقة	الهجمات المكتشفة
1	Web Server (access.log بصيغة Nginx/Apache)	Application Layer	SQL Injection، Directory Traversal، Scanning/Fuzzing (كثرة 404/403 من نفس IP)
2	Auth/OS (auth.log بصيغة Linux SSH)	Endpoint/OS Layer	Brute Force، دخول ناجح بعد فشل متكرر
3	Firewall (firewall.log بصيغة iptables)	Network Layer	Port Scanning (تعدد المنافذ المحظورة من نفس IP)

اختيار هذه الطبقات الثلاث معًا (شبكة + نظام + تطبيق) يعطي رؤية شاملة تشبه أي SIEM حقيقي.

2) طريقة التشغيل

# 1. توليد سجلات تجريبية (أو استبدل logs/*.log بسجلاتك الحقيقية)
python3 generate_sample_logs.py

# 2. تشغيل التحليل مرة واحدة
python3 siem_analyzer.py --once

# أو تشغيل دوري (محاكاة عمل خدمة SIEM حية) كل 30 ثانية
python3 siem_analyzer.py --watch 30

# 3. تشغيل خادم محلي بسيط لعرض اللوحة (ضروري كي تستطيع اللوحة قراءة alerts.json عبر fetch)
python3 -m http.server 8000

# 4. افتح المتصفح على:
http://localhost:8000/dashboard.html

ملاحظة: إذا فتحت dashboard.html مباشرة (بدون خادم)، أضفنا زر "تحميل alerts.json يدويًا" في اللوحة كحل بديل يعمل بدون أي خادم.

لاستخدام سجلاتك الحقيقية بدلاً من التجريبية، عدّل المسارات في أعلى siem_analyzer.py:

CONFIG = {
    "web_log_path": "/var/log/nginx/access.log",
    "auth_log_path": "/var/log/auth.log",
    "firewall_log_path": "/var/log/iptables.log",
    ...
}

3) منطق الكشف (Detection Logic) باختصار

• SQL Injection / Traversal: تعابير قياسية (Regex) تبحث عن UNION SELECT، OR 1=1، ../ ضمن الـ URL المطلوب.
• Scanning عبر الويب: عدّاد لكل IP لعدد أكواد 404/403؛ إذا تجاوز الحد (15 افتراضيًا) → تنبيه.
• Brute Force: عدّاد محاولات Failed password لكل IP خلال الملف؛ إذا تجاوز 5 محاولات → تنبيه، ويُرفع لمستوى "حرج" إذا نجح الدخول بعدها.
• Port Scanning: تجميع المنافذ الفريدة (set) التي حاول كل IP الوصول إليها وتم رفضها (DROP/REJECT/BLOCK)؛ إذا تجاوزت 15 منفذًا → تنبيه.

كل الحدود (Thresholds) قابلة للتعديل من قاموس CONFIG أعلى ملف siem_analyzer.py.

4) تصميم الـ Dashboard

• بطاقات إحصائية علوية (إجمالي التنبيهات، حرجة، عالية، IP مشبوهة).
• جدول التنبيهات كاملاً مرتب حسب الخطورة.
• جدول عناوين IP المشبوهة مع درجة الخطورة (Score) المحسوبة من وزن كل تنبيه.
• رسم بياني بسيط (أعمدة) لعدد التنبيهات حسب المصدر.
• تحديث تلقائي كل 10 ثوانٍ عبر fetch، بالإضافة لزر تحديث يدوي وزر رفع ملف JSON يدويًا.

---

5) النشر على غيمة (Cloud) باستخدام Block Storage — الجزء المطلوب في السؤال الثالث

الفكرة العامة

الهدف من استخدام Block Storage هنا هو فصل بيانات السجلات (Logs) عن دورة حياة الخادم (VM)، بحيث:

• إذا تم حذف/إعادة بناء الخادم، لا تُفقد السجلات التاريخية.
• يمكن أخذ نسخ احتياطية (Snapshots) لوحدة التخزين بشكل مستقل عن الخادم.
• يمكن فصل الوحدة وتوصيلها بخادم آخر (مثلاً خادم تحليل مخصص) دون نقل بيانات فعليًا.

خطوات النشر (عامة، تنطبق على أغلب مزودي الغيمة)

1. إنشاء خادم افتراضي (VM/Instance) لتشغيل السكربتات ولوحة الـ Dashboard (يكفي حجم صغير: 1-2 vCPU، 1-2GB RAM).

2. إنشاء وحدة Block Storage منفصلة (مثلاً 20-50GB حسب حجم السجلات المتوقع) وربطها (Attach) بالخادم.

3. تهيئة ووصل الوحدة (Mount) داخل الخادم:

   sudo mkfs.ext4 /dev/vdb          # تهيئة الوحدة (مرة واحدة فقط)
   sudo mkdir -p /mnt/siem-storage
   sudo mount /dev/vdb /mnt/siem-storage
   echo "/dev/vdb /mnt/siem-storage ext4 defaults 0 2" | sudo tee -a /etc/fstab   # لضمان الوصل التلقائي بعد إعادة التشغيل
   

4. نقل مجلدي logs/ و output/ إلى وحدة التخزين، وتحديث المسارات في CONFIG داخل siem_analyzer.py:

   CONFIG = {
       "web_log_path": "/mnt/siem-storage/logs/access.log",
       "auth_log_path": "/mnt/siem-storage/logs/auth.log",
       "firewall_log_path": "/mnt/siem-storage/logs/firewall.log",
       "output_path": "/mnt/siem-storage/output/alerts.json",
       ...
   }
   

5. تشغيل التحليل كخدمة دائمة (systemd) بدلاً من تشغيله يدويًا، مثال siem-analyzer.service:

   [Unit]
   Description=SIEM Log Analyzer
   After=network.target
   
   [Service]
   ExecStart=/usr/bin/python3 /opt/siem/siem_analyzer.py --watch 60
   Restart=always
   User=siem
   
   [Install]
   WantedBy=multi-user.target
   

   sudo systemctl enable --now siem-analyzer
   

6. تشغيل الـ Dashboard عبر خادم ويب حقيقي (بدلاً من http.server) مثل Nginx، بحيث يخدم:

   • dashboard.html كصفحة ثابتة.
   • output/alerts.json (الموجود فعليًا على وحدة الـ Block Storage المُوصولة) كملف بيانات يُقرأ عبر fetch.

7. (اختياري) نسخ احتياطي دوري: جدولة Snapshot يومي لوحدة الـ Block Storage عبر لوحة تحكم مزود الغيمة، لحفظ تاريخ السجلات والتنبيهات بشكل مستقل عن الخادم نفسه.

لماذا Block Storage تحديدًا (وليس تخزين محلي على القرص الافتراضي للخادم)؟

• الاستمرارية (Persistence): تخزين القرص الافتراضي المرفق افتراضيًا بالخادم (Root Disk) قد يُفقد عند حذف الخادم؛ Block Storage وحدة مستقلة يمكن الاحتفاظ بها.
• قابلية التوسع (Scalability): يمكن زيادة حجم الوحدة لاحقًا دون التأثير على الخادم نفسه، مهم لأن حجم السجلات يكبر مع الوقت.
• قابلية النقل: يمكن فصل الوحدة وربطها بخادم تحليل آخر (مثلاً خادم أقوى لتشغيل تحليل أعمق) دون نسخ نيوتيرا (TB) من البيانات عبر الشبكة.