أنهيت الإمتحان

q4-siem-log-analysis/README.md

@@ -0,0 +1,134 @@
+# نظام 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) طريقة التشغيل
+
+```bash
+# 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`:
+```python
+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)** داخل الخادم:
+   ```bash
+   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`:
+   ```python
+   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`:
+   ```ini
+   [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
+   ```
+   ```bash
+   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) من البيانات عبر الشبكة.