الملفات
2026-07-27 22:32:29 +03:00

135 أسطر
7.9 KiB
Markdown

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