diff --git a/common-mortakaz/integration.md b/common-mortakaz/integration.md new file mode 100644 index 0000000..bc93728 --- /dev/null +++ b/common-mortakaz/integration.md @@ -0,0 +1,67 @@ +# Integration Proposal 1: "Masar" (مسار) x mithal.space + +## 1. وصف المنتج المختار +**"مسار" (Masar):** أداة عربية مبتكرة لفك الروابط المختصرة وكشف وجهتها الأصلية. تهدف الأداة إلى تعزيز الأمان والخصوصية للمستخدمين من خلال فحص الروابط قبل النقر عليها وحمايتهم من التتبع الخفي أو مواقع التصيد (Phishing). + +## 2. كيف يتكامل مع mithal.space؟ +بما أن `mithal.space` محرك بحث يركز على الخصوصية، سيتم دمج واجهة برمجة تطبيقات (API) الخاصة بـ "مسار" في خوارزمية عرض النتائج. عند ظهور أي رابط مختصر (مثل bit.ly أو غيره) ضمن نتائج البحث، يقوم المحرك بتمريره في الخلفية لـ "مسار" لفكه وتحليله، ثم يعرض للمستخدم الرابط الوجهة الحقيقي مع "درع أمان" (Safety Badge) يوضح ما إذا كان الرابط يحتوي على متتبعات إعلانية أو برمجيات خبيثة. + +## 3. القيمة المضافة للمستخدم النهائي +- **شفافية مطلقة:** لن يضطر المستخدم للنقر الأعمى على الروابط المختصرة في نتائج البحث. +- **حماية استباقية للخصوصية:** منع نصوص التتبع (Trackers) التي تعتمد على تحويلات الروابط (Redirects) من التقاط بيانات المستخدم (مثل IP Address) بمجرد النقر. +- **تعزيز الثقة:** ترسيخ مكانة `mithal.space` كمحرك البحث العربي الأكثر أماناً. + +## 4. رسم هيكلي بسيط (Architecture Sketch) +```text +[User Search Query] + | + v +[mithal.space Engine] ---> (Finds Shortened URL in Results) + | + +---> [Masar API] ---> (Expands URL & Scans for Trackers) + | | + |<---------+ (Returns Original URL + Security Status) + v +[Safe Search Results Rendered to User with Warnings/Badges] + +5. التحديات التقنية أو التجارية المحتملة +التحديات التقنية: فك الروابط يستدعي عمل HTTP Requests إضافية، مما قد يزيد من زمن استجابة صفحة البحث (Latency). يتطلب ذلك نظام تخزين مؤقت (Caching) عالي الكفاءة للروابط المفحوصة مسبقاً. +التحديات التجارية: تكلفة استهلاك خوادم "مسار" مع كل عملية بحث، مما يستلزم عقد شراكة استراتيجية (B2B) بين المنصتين لتحمل تكاليف البنية التحتية. +--- + + +```markdown +# Integration Proposal 2: "Cyber Ninja" x ghaymah.systems + +## 1. وصف المنتج المختار +**"Cyber Ninja":** أداة عربية متطورة لفحص أمان المواقع الإلكترونية، متخصصة في الكشف عن الثغرات والمشكلات الأمنية بسرعة فائقة، وتقديم تقييم أمني شامل بناءً على المعايير العالمية (مثل OWASP). + +## 2. كيف يتكامل مع ghaymah.systems؟ +سيتم دمج أداة "Cyber Ninja" كخدمة مدمجة (Native Add-on) داخل لوحة تحكم البنية التحتية السحابية لـ `ghaymah.systems`. يمكن للمطورين ومهندسي العمليات تفعيل "فحص أمان تلقائي" كجزء من خط أنابيب النشر (CI/CD Pipeline). بمجرد نشر تطبيق جديد أو حاوية (Container) على خوادم غيمة، تقوم "Cyber Ninja" بإجراء فحص ديناميكي (DAST) للتطبيق المرفوع وتوليد تقرير أمني فوري. + +## 3. القيمة المضافة للمستخدم النهائي (عملاء غيمة) +- **أمان مدمج (Security by Default):** يحصل عملاء غيمة على أداة فحص ثغرات جاهزة دون الحاجة لتهيئة أدوات خارجية معقدة. +- **توفير الوقت:** أتمتة التدقيق الأمني بدلاً من الفحص اليدوي، مما يسرع من دورة حياة تطوير البرمجيات (SDLC). +- **ميزة تنافسية لغيمة:** تقديم البنية التحتية السحابية (IaaS) مع طبقة عمليات أمنية (SecOps) جاهزة، مما يجذب الشركات الكبرى والحكومية التي تتطلب امتثالاً أمنياً صارماً. + +## 4. رسم هيكلي بسيط (Architecture Sketch) +```text +[Developer] ---> (Pushes Code / Deploys App) ---> [Ghaymah CI/CD Pipeline] + | + v +[Ghaymah App Environment] <--- (Automated DAST Scan) <--- [Cyber Ninja Integration] + | + v + [Security Audit Report] + | + +----------------------+----------------------+ + | | + [Pass: Deploy] [Fail: Block & Alert] + +5. التحديات التقنية أو التجارية المحتملة +التحديات التقنية: الفحص الأمني الديناميكي قد يتسبب في ضغط إضافي على موارد الشبكة والخوادم (CPU/Bandwidth) الخاصة بالعميل أثناء عملية الفحص، مما يتطلب جدولة ذكية لأوقات الفحص. +التحديات التجارية: التعامل مع النتائج الإيجابية الخاطئة (False Positives) التي قد توقف نشر تطبيقات سليمة وتسبب إزعاجاً للمطورين. +أي المنتجين تعتقد أنه الأكثر قابلية للتطبيق؟ ولماذا؟ +تكامل "Cyber Ninja" مع ghaymah.systems هو الأكثر قابلية للتطبيق تجارياً وتقنياً. لأن خدمات الحوسبة السحابية تعتمد بشكل أساسي على توفير بيئة آمنة للعملاء (B2B). دمج أداة متخصصة في اكتشاف الثغرات كجزء من البنية التحتية يلبي حاجة حرجة وأساسية في سوق الحوسبة السحابية، ويسهل تحقيق عائد مادي منه (Monetization) عبر بيعه كخدمة إضافية (Security as a Service) للمؤسسات التي تستضيف تطبيقاتها على منصة غيمة، بخلاف إضافات محركات البحث التي غالباً ما تواجه تحديات في إيجاد نموذج ربحي مباشر. + + diff --git a/q4-siem/alerts.json b/q4-siem/alerts.json new file mode 100644 index 0000000..96d854b --- /dev/null +++ b/q4-siem/alerts.json @@ -0,0 +1,12 @@ +[ + { + "ip": "192.168.1.50", + "threat_score": 100, + "events": [ + "Web Brute Force Attempt", + "SSH Failed Login", + "SQL Injection Attempt" + ], + "status": "Critical" + } +] \ No newline at end of file diff --git a/q4-siem/analyzer.py b/q4-siem/analyzer.py new file mode 100644 index 0000000..aa2035c --- /dev/null +++ b/q4-siem/analyzer.py @@ -0,0 +1,129 @@ +""" +Ghaymah SIEM - Log Correlation Analyzer +----------------------------------------- +Correlates events across 3 log sources (Web/Nginx, SSH/Auth, Database) to +detect a single attacker IP behind multiple attack patterns. + +Usage: + python3 analyzer.py -> runs on built-in demo data + python3 analyzer.py web.log auth.log db.log -> runs on real log files + +When real file paths are given, only NEW lines since the last run are +processed (tracked via analyzer_state.json), so this script is safe to run +every minute from a cron job without re-scoring the same events twice. +""" +import json +import re +import os +import sys +from collections import defaultdict + +STATE_FILE = "analyzer_state.json" + +# --- Demo data (used only when no real log paths are provided) --- +DEMO_WEB_LOGS = [ + "192.168.1.50 - POST /login HTTP/1.1 401 Unauthorized", + "192.168.1.50 - POST /login HTTP/1.1 401 Unauthorized", + "192.168.1.50 - POST /login HTTP/1.1 401 Unauthorized", + "10.0.0.5 - GET /index.html HTTP/1.1 200 OK", +] +DEMO_SSH_LOGS = [ + "Failed password for root from 192.168.1.50 port 22 ssh2", + "Accepted password for admin from 10.0.0.2 port 22 ssh2", +] +DEMO_DB_LOGS = [ + "Query executed by 192.168.1.50: SELECT * FROM users WHERE id = '1' OR '1'='1'", + "Query executed by 10.0.0.2: SELECT name FROM products WHERE id = 5", +] + + +def load_state(): + if os.path.exists(STATE_FILE): + with open(STATE_FILE) as f: + return json.load(f) + return {} + + +def save_state(state): + with open(STATE_FILE, "w") as f: + json.dump(state, f) + + +def read_new_lines(path, state): + """Read only the lines appended to `path` since the last recorded offset.""" + if not path or not os.path.exists(path): + return [] + last_offset = state.get(path, 0) + with open(path, "r", errors="ignore") as f: + f.seek(last_offset) + new_lines = f.readlines() + state[path] = f.tell() + return [line.strip() for line in new_lines if line.strip()] + + +def flag(bucket, reason, weight): + """Add score/reason to an IP bucket, without duplicating the same reason twice.""" + bucket["score"] += weight + if reason not in bucket["reasons"]: + bucket["reasons"].append(reason) + + +def analyze_logs(web_path=None, ssh_path=None, db_path=None): + using_real_files = any([web_path, ssh_path, db_path]) + state = load_state() if using_real_files else {} + + web_logs = read_new_lines(web_path, state) if web_path else DEMO_WEB_LOGS + ssh_logs = read_new_lines(ssh_path, state) if ssh_path else DEMO_SSH_LOGS + db_logs = read_new_lines(db_path, state) if db_path else DEMO_DB_LOGS + + suspicious_ips = defaultdict(lambda: {"score": 0, "reasons": []}) + + # Web logs -> Brute Force detection + for log in web_logs: + if "401 Unauthorized" in log: + ip = log.split()[0] + flag(suspicious_ips[ip], "Web Brute Force Attempt", 10) + + # SSH logs -> server intrusion attempts + for log in ssh_logs: + if "Failed password" in log: + match = re.search(r"from (\d+\.\d+\.\d+\.\d+)", log) + if match: + flag(suspicious_ips[match.group(1)], "SSH Failed Login", 20) + + # DB logs -> SQL Injection patterns + for log in db_logs: + if "OR '1'='1'" in log or "DROP TABLE" in log.upper(): + match = re.search(r"by (\d+\.\d+\.\d+\.\d+):", log) + if match: + flag(suspicious_ips[match.group(1)], "SQL Injection Attempt", 50) + + # Build alerts with severity tiers instead of a flat "Critical" for everything + alerts = [] + for ip, data in suspicious_ips.items(): + if data["score"] >= 30: + severity = "Critical" if data["score"] >= 50 else "Warning" + alerts.append({ + "ip": ip, + "threat_score": data["score"], + "events": data["reasons"], + "status": severity, + }) + + alerts.sort(key=lambda a: a["threat_score"], reverse=True) + + with open("alerts.json", "w") as f: + json.dump(alerts, f, indent=4) + + if using_real_files: + save_state(state) + + print(f"Analysis complete. {len(alerts)} alert(s) saved to alerts.json") + + +if __name__ == "__main__": + args = sys.argv[1:] + web_p = args[0] if len(args) > 0 else None + ssh_p = args[1] if len(args) > 1 else None + db_p = args[2] if len(args) > 2 else None + analyze_logs(web_p, ssh_p, db_p) diff --git a/q4-siem/dashboard.html b/q4-siem/dashboard.html new file mode 100644 index 0000000..d0cf617 --- /dev/null +++ b/q4-siem/dashboard.html @@ -0,0 +1,79 @@ + + + + + Ghaymah SIEM Dashboard + + + + +

لوحة تحكم SIEM - التنبيهات الأمنية

+

جاري التحميل...

+ + + + + + + + + + + + + +
عنوان IP المشبوهدرجة الخطورةالأحداث المرصودة (الأنماط)الحالة
+ + + + diff --git a/q4-siem/deployment-plan.md b/q4-siem/deployment-plan.md new file mode 100644 index 0000000..e7e305b --- /dev/null +++ b/q4-siem/deployment-plan.md @@ -0,0 +1,30 @@ +# SIEM Deployment Strategy on Ghaymah Cloud + +## 0. اختبار محلي قبل النشر (Local Testing Note) +`dashboard.html` بيستخدم `fetch()` لقراءة `alerts.json`، وده **مش هيشتغل لو فتحت الملف مباشرة بدبل كليك** (`file://`) بسبب سياسة الـ CORS في المتصفحات الحديثة. للتجربة محلياً قبل الرفع: +```bash +python3 analyzer.py # يولّد alerts.json +python3 -m http.server 8000 # يشغّل الملفين على HTTP بدل file:// +``` +ثم فتح `http://localhost:8000/dashboard.html`. بعد النشر على غيمة، NGINX هيحل المشكلة دي تلقائياً لأنه بيقدّم الملفات عبر HTTP فعلياً (تفاصيل في القسم 3). + +## 1. Storage Architecture (هيكلية التخزين) +نظراً لأن سجلات النظام (Logs) تتضخم بسرعة، لا يجب تخزينها على القرص الأساسي للخادم (OS Disk). +- **الخطوة:** سيتم إنشاء `Block Storage Volume` بحجم مناسب (مثلاً 500GB) من لوحة تحكم "غيمة". +- **التجهيز:** سيتم ربط (Attach) البلوك بالسيرفر وعمل Mount له في مسار مخصص، وليكن `/var/log/ghaymah_siem/`. +- **الميزة:** هذا يضمن عدم توقف السيرفر عن العمل إذا امتلأت مساحة السجلات (Disk Full)، ويسمح بأخذ نسخ احتياطية للـ Volume بشكل مستقل. +- **التشفير:** يتم تفعيل تشفير الـ Block Storage نفسه (Encryption at Rest)، ويُفضّل أن تكون النسخ الاحتياطية للـ Volume غير قابلة للحذف (Immutable) لمدة محددة، لضمان بقاء الأدلة الجنائية (Forensic Evidence) سليمة حتى في حال اختراق السيرفر نفسه. + +## 2. Automation & Execution (التشغيل التلقائي) +- سيتم تشغيل `analyzer.py` كـ `Cron Job` يعمل كل دقيقة، مع تمرير مسارات ملفات الـ Logs الحقيقية على الـ Block Storage كـ arguments: + ```bash + * * * * * /usr/bin/python3 /opt/siem/analyzer.py /var/log/ghaymah_siem/web.log /var/log/ghaymah_siem/auth.log /var/log/ghaymah_siem/db.log + ``` +- السكريبت بيحتفظ بموقع آخر سطر اتقرا لكل ملف في `analyzer_state.json`، فكل تشغيل بيعالج **الأسطر الجديدة بس** — ده مهم جداً لأن الـ Logs بتتزايد باستمرار، ولو كل تشغيل أعاد قراءة الملف كامل، الـ CPU هتتحمّل فوق طاقتها والـ Alerts هتتكرر لنفس الحدث. +- السكريبت بيحدّث `alerts.json` بشكل دوري، والداشبورد بيعمل Auto-Refresh كل 30 ثانية. + +## 3. Dashboard Hosting (استضافة الواجهة) +- سيتم استخدام `NGINX` كـ Web Server خفيف لاستضافة `dashboard.html` و `alerts.json` (وده بيحل مشكلة الـ CORS في القسم 0 تلقائياً لأن الاستضافة بقت عبر HTTP وليس فتح ملف محلي). +- سيتم توجيه NGINX لقراءة الواجهة وملف الـ JSON من المسار المعزول على الـ Block Storage. +- سيتم تأمين مسار الداشبورد باستخدام Basic Authentication و HTTPS (شهادة Let's Encrypt) لضمان عدم وصول أي شخص غير مصرح له لبيانات التنبيهات الأمنية. +- **تكامل مع Rate Limiting:** بما إن الداشبورد بيعرض بيانات حساسة عن هجمات فعلية، يُنصح بتطبيق نفس مبدأ Rate Limiting المستخدم في تأمين الـ API (راجع تقرير الـ Postmortem) على مسار تسجيل الدخول لصفحة الداشبورد نفسها. diff --git a/q5-ransomware/Ransomware-response.md b/q5-ransomware/Ransomware-response.md new file mode 100644 index 0000000..2fe687d --- /dev/null +++ b/q5-ransomware/Ransomware-response.md @@ -0,0 +1,65 @@ +# Ransomware Incident Response & Recovery Plan +**Target:** Ghaymah Cloud Block Storage | **Severity:** CRITICAL + +## 1. Emergency Response Plan (أول 60 دقيقة) + +في حالة اكتشاف تشفير ملفات الـ Block Storage، يتم تفعيل بروتوكول الطوارئ فوراً خلال الساعة الأولى (Golden Hour): + +1. **الاحتواء والعزل (Containment & Isolation - 0 to 15 mins):** + - فصل خوادم التطبيقات المصابة عن الشبكة فوراً (Network Isolation) لمنع انتشار التشفير (Lateral Movement) إلى خوادم أو شبكات أخرى. + - **عدم إعادة تشغيل الخوادم (No Reboot):** قد يؤدي الريستارت إلى فقدان مفاتيح تشفير مؤقتة في الـ RAM كانت ممكن تساعد في فك التشفير لاحقاً، أو تشغيل سكريبتات تدميرية إضافية مبرمجة على حدث الـ Reboot. + - فصل الـ Block Storage المصاب برمجياً (Detach) من الخوادم وتحويله إلى حالة (Read-Only). + +2. **حماية النسخ الاحتياطية وفحص التسريب (Backup Protection & Exfiltration Check - 15 to 30 mins):** + - قطع أي اتصال شبكي بين بيئة الإنتاج (Production) وبيئة النسخ الاحتياطي (Backup Servers). + - مراجعة سلامة آخر لقطات (Snapshots) تم أخذها قبل توقيت الهجوم للتأكد من عدم تشفيرها. + - **فحص سجلات الـ Egress Traffic** لتحديد هل الهجوم كان تشفير فقط، أم **Double Extortion** (تسريب البيانات قبل التشفير) — ده بيغيّر خطة التواصل مع العملاء والإدارة القانونية بالكامل. + +3. **التقييم والتواصل (Triage & Communication - 30 to 60 mins):** + - تفعيل فريق الاستجابة الكامل (War Room)، وإبلاغ الإدارة العليا والفريق القانوني بالحادثة، والاستعانة بفريق DFIR متخصص خارجي إذا لزم الأمر. + - تحديد نقطة الاستعادة (RPO) السليمة للبدء في تجهيز بيئة تعافي جديدة (Clean Environment) بعيداً تماماً عن البيئة المخترقة. + +--- + +## 2. Ghaymah Backup & Recovery Strategy (استراتيجية التعافي) + +نرفض تماماً التفاوض أو دفع الفدية، ونعتمد على استراتيجية التعافي التالية: + +- **RPO (Recovery Point Objective):** لا يتجاوز **1 ساعة**، عبر جدولة Automated Snapshots للـ Block Storage كل ساعة. أقصى خسارة للبيانات هي آخر 60 دقيقة فقط. +- **RTO (Recovery Time Objective):** لا يتجاوز **4 ساعات**، باستخدام Infrastructure as Code (Terraform) لإعادة بناء الخوادم سريعاً وربطها بالـ Snapshots السليمة. + +**تطبيق قاعدة (3-2-1) على منصة غيمة:** +- **3 نسخ:** البيانات الحية على الـ Block Storage + نسخة Backup قريبة + نسخة Backup ممتدة. +- **2 وسائط:** النسخة القريبة على Fast Block Storage لسرعة الاسترجاع، والنسخة الممتدة على Object Storage (Cold Tier) بتكلفة أقل. +- **1 موقع معزول:** نسخة الـ Object Storage في حساب منفصل تماماً (Cross-Account)، مع تفعيل **Object Lock (Immutable)** لمدة 30 يوماً، بحيث حتى لو سرق الهاكر صلاحيات Root في بيئة الإنتاج، لا يقدر يعدّل أو يحذف النسخ الاحتياطية. + +**🚧 بوابة إلزامية قبل أي استرجاع (Eradication Gate — قبل الـ Recovery مش بعده):** +الـ RTO مش بس "وقت بناء السيرفرات"، لازم يشمل التأكد من إغلاق نقطة الدخول الأصلية اللي دخل منها الهاكر (Patch الثغرة، تغيير كل الـ Credentials المشبوهة، إزالة أي Persistence). **استرجاع الباك أب في بيئة لسه مخترقة = إعادة تشفير فورية.** لذلك خطوات الاسترجاع الفعلية تكون: +1. بناء بيئة نظيفة معزولة تماماً عن الشبكة القديمة (مش نفس الـ VPC). +2. استرجاع الداتا من آخر Snapshot سليم فيها. +3. فحص أمني كامل للبيئة الجديدة قبل ربطها بالإنترنت أو بالمستخدمين. + +**اختبار دوري للاسترجاع (DR Drills):** الباك أب اللي مش بيتعمله Test استرجاع فعلي كل فترة (مثلاً كل 3 شهور) هو باك أب مش مضمون. يُنصح بجدولة Restore Drill ربع سنوي للتأكد إن الـ RTO المذكور فعلاً قابل للتحقيق. + +--- + +## 3. Prevention & Hardening Plan (خطة الوقاية الشاملة) + +لمنع تكرار هجوم الـ Ransomware مستقبلاً، سيتم تطبيق السياسات التالية: + +1. **إغلاق نقطة الدخول الأساسية (Patch & Phishing Defense):** + أغلب هجمات الـ Ransomware بتدخل من ثغرة مش متحدثة (Unpatched Vulnerability) أو إيميل Phishing — مش من هجوم متقدم. لازم: + - جدولة منتظمة لـ Vulnerability Scanning وتطبيق الـ Patches على كل الخوادم والـ Container Images (زي Trivy scanning). + - تدريب دوري للموظفين على التعرف على رسائل الـ Phishing، وتفعيل فلترة البريد الإلكتروني. + +2. **تأمين الوصول والصلاحيات (Zero Trust & IAM):** + - تطبيق المصادقة الثنائية (MFA) بشكل إلزامي على جميع لوحات التحكم وأنظمة الوصول (SSH/VPN). + - استخدام نظام إدارة أسرار مركزي (Secrets Manager / HashiCorp Vault) بدل تخزين أي كلمات مرور أو مفاتيح API داخل الكود أو الـ Block Storage. + +3. **تقسيم الشبكة الدقيق (Micro-segmentation):** + - عزل بيئات العمل (Dev, Staging, Prod) في شبكات افتراضية منفصلة (VPCs/Namespaces) بحيث لا يقدر فيروس الفدية ينتقل من خادم تطوير لخادم إنتاج. + +4. **المراقبة المتقدمة (SIEM & Endpoint Protection):** + - نشر وكلاء حماية (EDR) على جميع الخوادم لمراقبة سلوكيات التشفير غير الطبيعية في الوقت الفعلي. + - ربط السجلات بنظام الـ SIEM (المصمم في Q4) لإنشاء تنبيهات فورية عند اكتشاف عمليات قراءة/كتابة (I/O) مكثفة وغير مبررة على الـ Block Storage — وهو بالظبط النمط اللي كان هيكشف هجوم التشفير ده مبكراً لو كان شغال وقتها. +