# نظام 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) من البيانات عبر الشبكة.