• يجمع بيانات القياس عن بُعد من وكلاء ويندوز ولينكس عبر قناة TCP واحدة. أحداث SIEM، والتنبيهات، وFIM، والحزم، واتصالات الشبكة، والمنافذ المفتوحة، ونشاط Docker، ولقطات الشاشة.

• يكتشف باستخدام قواعد Sigma، على نقطة النهاية. 23 قاعدة تغطي 23 تقنية من MITRE ATT&CK مرفقة في conf/sigma/builtin/؛ ضع مجموعات قواعد المجتمع بجانبها. تطابق Sigma الحقول المسماة بدلاً من النص، لذا لا يمكن هزيمة Image|endswith: '\vssadmin.exe' بظهور كلمة "vssadmin" في رسالة غير ذات صلة — وCommandLine|utf16le|base64offset|contains يقرأ داخل حمولة -EncodedCommand المشفرة base64، حيث يُظهر سطر الأوامر النصي الغلاف فقط. مُقاس على مجموعة التقييم: 9 من 10 هجمات يكتشفها Sigma وحده، و0 من 9 سلبيات صعبة يتم الإبلاغ عنها خطأً. هذه الطبقة حتمية وتستمر في العمل عندما يكون النموذج غير متاح.

• يربط بين الأحداث عبر الزمن، وهو ما لا يمكن لأي قاعدة لكل حدث منفرد أن تفعله. تسجيل دخول فاشل واحد أمر روتيني؛ خمسة حسابات تفشل من مصدر واحد خلال أربعين ثانية هو هجوم رش كلمات مرور، والنظر إلى أي من تلك الأحداث الخمسة لن يخبرك بذلك أبدًا. يغطي الرش، والهجمات بالقوة الغاشمة، والنجاح الذي يصل بعد فشل متكرر، واندفاعات إنشاء الحسابات أو تثبيت الخدمات — على كلا النظامين، من معرفات أحداث ويندوز أو من أسطر auth.log المحللة.

  يعمل من نقطتي مراقبة، لأنهما ترى هجمات مختلفة. على المضيف في الوكيل، حيث يكون الهجوم ضد جهاز واحد مرئيًا بالكامل. وعبر المضيفين في مسار الاستيعاب، حيث يظهر الرش الذي سار فشلًا واحدًا في كل مرة عبر خمسين جهازًا — لا يرى أي وكيل منفرد أكثر من حدث واحد، وهذا هو الهجوم الأكثر كفاءة، لأن الرش الواسع والضحل يبقى تحت عتبات قفل الحساب وعتبات المضيف معًا.

  التغطية الإجمالية مع Sigma: 27 تقنية. كل نافذة تُطلق مرة واحدة بدلاً من مرة لكل حدث، وكل عداد محدود — العداد المرتبط باسم مستخدم يقدمه المهاجم هو بدائية استنزاف ذاكرة، وليس كشفًا.

• يربط الاكتشافات بـ MITRE ATT&CK، من القواعد نفسها. تحمل القواعد tags: attack.t1490، لذا لا يوجد جدول تعيين يُحفظ يدويًا ليصبح قديمًا. تفصل صفحة التغطية ثلاث حالات كانت "نسبة التغطية" الواحدة ستخفيها: مغطاة ومشاهدة، ومغطاة وهادئة، وغير مغطاة إطلاقًا — والأخيرة هي الوحيدة التي لا يعني فيها صمت لوحة التحكم شيئًا.

• يفرز كل حدث باستخدام LLM محلي. تعمل ثلاث عمليات بالتوازي: واحدة تراقب كل حدث وارد في الوقت الفعلي، وواحدة تدير فحوصات عميقة يقودها المشغل، وواحدة تقرر ما إذا كانت ستتخذ إجراءً دفاعيًا (BLOCK_IP، ISOLATE_HOST، KILL_PROCESS، إلخ).

• وضع الظل للعملية الدفاعية. فعّل AI_SHADOW_MODE=1 وسيتم وضع كل قرار مستقل في مرحلة موافقة بشرية في مركز SOAR بدلاً من تنفيذه. مفيد لضبط النموذج على حركة المرور الحقيقية قبل السماح له بالتصرف بمفرده.

• يفهرس كل شيء في OpenSearch حتى تتمكن من البحث في أسطولك باستعلامات غامضة / دقيقة / تبدأ بـ من مكان واحد.

• يشغّل قوائم تشغيل SOAR المبنية في محرر مرئي صغير مع تتبع نتائج متعدد الخطوات لكل عقدة، ويمكن تشغيلها يدويًا أو بقرار من الذكاء الاصطناعي.

• يفحص الثغرات في الحزم المثبتة لكل وكيل مقابل OSV (عبر الإنترنت أو عبر مرآة داخلية).

• يسحب خلاصات استخبارات التهديدات من abuse.ch (Feodo، ThreatFox، URLhaus) إلى جدول مؤشرات محلي، مع تقليم البيانات القديمة ومفتاح عزل الشبكة.

• يتحقق من صحة تكوينات الوكلاء قبل دفعها. تحليل YAML، والشكل البنيوي، وتجميع التعبيرات النمطية — التعبير النمطي غير الصالح هو YAML صالح ويعطل القاعدة التي تحتويه بصمت.

• سطح مكتب بعيد مدمج عبر بث JPEG عبر WebSocket، دون الحاجة إلى تثبيت VNC منفصل على نقطة النهاية.

كيف يبدو

يجمع الشريط الجانبي كل شيء في ثلاثة أقسام: القياس عن بُعد (لوحة التحكم، الوكلاء، التنبيهات، الأصول، FIM، السجلات، الذكاء الاصطناعي)، أتمتة الاستجابة (الإجراءات الدفاعية، قوائم التشغيل، قواعد الأتمتة)، والإدارة.

عرض كل وكيل

لكل وكيل مسجّل صفحته الخاصة مع اثنتي عشرة علامة تبويب. تعرض النظرة العامة عدادات الموارد الحية، وأحدث سجلات SIEM، وبيانات الوكيل الوصفية، وملخص التهديدات:

التنبيهات هي كل ما قامت قواعد الارتباط الخاصة بالوكيل نفسه بوضع علامة عليه بالفعل. ملونة حسب الخطورة، وقابلة للتصفية والبحث:

علامة التبويب تحليل الذكاء الاصطناعي هي الجانب الموجه للمشغل من LLM المحلي. الفحوصات اليدوية والآلية تهبط هنا معًا. يحمل كل استنتاج شارة حكم، ودرجة ثقة، ومؤشرات MITRE (عندما يعيدها النموذج)، ومؤشرات الاختراق (IOCs)، وخطوات تالية، وزر عرض المصدر الذي يفتح صف السجل الدقيق الذي نظر إليه الذكاء الاصطناعي:

جرد الأصول

الأجهزة والبرامج ومقابس الشبكة لكل وكيل. تعرض علامة تبويب الأجهزة كل جهاز PnP، وتعرض البرامج الحزم المثبتة، وتعرض الشبكة كل مقبس TCP/UDP مع العملية المالكة له:

مستكشف السجلات

بحث عبر الوكلاء مدعوم بـ OpenSearch. اختر وكيلًا، واختر مجموعة بيانات (أحداث SIEM، تنبيهات الأمان، أحداث العمليات، الشبكة، FIM، سجلات التدقيق)، وابحث. يوجد أيضًا زر لفتح OpenSearch Dashboards (فرع Kibana) للمستخدمين المتقدمين:

سجلات التدقيق

كل محاولة تسجيل دخول ضد المنصة نفسها، محلية وLDAP، مع النتيجة وعنوان IP المصدر والطابع الزمني. مفيد عندما يكون شخص ما في مزاج "من سجّل الدخول ومتى":

بدء سريع

ستحتاج إلى Docker 24+ مع Compose v2 وPython 3.10+ على المضيف (فقط لخطوة بناء الوكيل لمرة واحدة). تتطلب الحزمة الكاملة حوالي 16 جيجابايت من ذاكرة الوصول العشوائي، انظر متطلبات النظام أدناه.```bash git clone https://github.com/d3vhex/Sentora.git cd Sentora

.env holds your local secrets. Never commit it.

cp .env.example .env

Generate the machine-generated secrets (FERNET_KEY, RABBITMQ_PASSWORD,

AGENT_SHARED_SECRET, OPENSEARCH_PASSWORD). Safe to re-run — it never

overwrites a value that is already set.

python scripts/init_secrets.py

Then set DB_PASSWORD by hand. Compose refuses to start without it.

On an existing deployment, rotate it with scripts/rotate_db_password.py

instead — MySQL fixes the root password at first init, so editing .env

alone locks the app out rather than changing the account.

Build the agent binary once. The server serves it via

/api/agent/download/{linux,windows}; skipping this means agents can't be

deployed because the download endpoint returns 404.

cd Sentora ./build_agent.sh # on Linux/macOS/WSL

.\build_agent.ps1 # on Windows

cd ..

docker compose up --build -d

نشر وكيل: من صفحة Deploy Agent، انسخ الأمر أحادي السطر لنظام التشغيل الذي تريده. على الجهاز الهدف (قشرة إدارية)، الصقه. يقوم المثبّت بتنزيل الملف الثنائي، ويضع ملف إعداد، ويسجّل الوكيل مع الخادم، ويُسجّله كمهمة مجدولة / وحدة systemd.

الخدمات في compose

فقط app و ingest يستمعان على جميع الواجهات. البقية مرتبطة بـ BIND_ADDR (الافتراضي 127.0.0.1)، لأن أياً منها لا يتحقق من الهوية في الإعداد الافتراضي — يعمل OpenSearch مع تعطيل إضافة الأمان الخاصة به و Dashboards هي عرض غير موثّق لكل سجل تم جمعه. اكشف أحدها بوضعه خلف نفس الوكيل العكسي والمصادقة مثل app، وليس بتوسيع BIND_ADDR.

زر "Open Dashboards" في Log Explorer يرتبط بالمنفذ 5601 على اسم مضيف الخادم، لذا يعمل من المضيف نفسه؛ يحتاج المشغّلون عن بُعد إلى ذلك الوكيل العكسي.

متطلبات النظام

البصمة في وضع الخمول:

• Ollama (llama3.2:3b): ~3 GB، أكثر أثناء الاستدلال
• OpenSearch: ~2 GB كومة افتراضية، ينمو القرص مع فترة الاحتفاظ
• MySQL: 500 MB – 1 GB
• RabbitMQ: ~300 MB
• Sanic + ingest + 3 عمال AI: ~1 GB مجتمعة

إذا كانت الذاكرة محدودة لديك، بدّل إلى qwen2.5:1.5b أو نموذج Ollama صغير آخر وقلّص كومة OpenSearch. وحدة معالجة رسومية غير مطلوبة لكن Ollama سيستخدمها تلقائياً إذا كانت موجودة.

إجراءات AI الدفاعية التلقائية

عندما يكون حكم العامل الدفاعي ACT بثقة ≥ AI_AUTO_ACT_CONF (الافتراضي 0.75) والإجراء الموصى به موجود في القائمة الآمنة أدناه، يضع العامل الإجراء مباشرة في جدول automations الخاص بالوكيل:``` BLOCK_IP KILL_PROCESS RESTART_SERVICE ISOLATE_HOST DISABLE_USER QUARANTINE_FILE SUSPEND_PROCESS LOGOFF_USER CONTAINER_ISOLATE CONTAINER_STOP CONTAINER_KILL

إذا أبلغ هذا السطر عن 0 permission-gated، فإن RBAC لا يتم تطبيقه — تعامل معه على أنه انقطاع.

يجب أن يكون كل مسار واحدًا من ثلاثة أشياء: مقيدًا بالأذونات، أو مدرجًا في _PUBLIC_HANDLERS، أو مذكورًا في SESSION_ONLY_HANDLERS في tests/test_auth_wiring.py مع تعليق يوضح لماذا الجلسة وحدها كافية. يتحقق اختبار من ذلك، لذا لا يمكن لمسار جديد أن يصل دون حوكمة بهدوء — وهكذا انتهى الأمر بـ run_playbook وdelete_soar_action وtest_ldap_connection ليكون قابلاً للوصول من قبل أي حساب يمكنه تسجيل الدخول.

تقييد تسجيل الدخول

خمس محاولات فاشلة لحساب واحد، أو عشرون من عنوان واحد، خلال خمس عشرة دقيقة، ويتم رفض المحاولات الإضافية برمز 429 حتى تمر النافذة. يتم العد من login_logs، الذي كان يسجل بالفعل كل فشل ولم يقرأه أحد — كان bcrypt هو الفرامل الوحيدة على التخمين عبر الإنترنت.

يتم الفحص قبل مقارنة كلمة المرور، لذا فهو يزيل أيضًا فرق التوقيت بين اسم مستخدم معروف وآخر غير معروف. يفشل بشكل مفتوح إذا كان login_logs غير قابل للوصول: صفحة تسجيل دخول لا يمكن الوصول إليها لأن جدول التدقيق معطل هي انقطاع بحد ذاتها.

عناوين العملاء خلف وكيل

يتم تكريم X-Forwarded-For فقط من نظير مدرج في TRUSTED_PROXIES (عناوين مفصولة بفواصل أو CIDRs، فارغة افتراضيًا). مع عدم وجود شيء أمام التطبيق، يكون الرأس مزودًا من قبل المهاجم، لذا فإن تصديقه دون قيد أو شرط — وهو ما حل هذا محلّه — سمح للمتصل بكتابة أي عنوان في سجل التدقيق وإعادة تعيين حد المعدل الخاص به في نفس الطلب.``` TRUSTED_PROXIES=10.0.0.0/8,192.168.1.5

المفاتيح القديمة ما تزال موجودة في تاريخ git. تعامل مع الزوج الذي تم إصداره قبل هذا التغيير على أنه محترق؛ التثبيتات الجديدة لم تعد تستخدمه.

مفاتيح Fernet المحلية

يستخدم الخادم مفتاحي Fernet، وكلاهما يتم توليده تلقائيًا عند أول تشغيل:

chmod 600 لكليهما. احتفظ بنسخة احتياطية منهما. فقدان أي منهما يجعل البيانات المشفرة المقابلة غير قابلة للقراءة. لا يوجد حتى الآن تدوير في المكان.

معلومات التهديدات

آليتان مستقلتان، وكلتاهما اختيارية:

إثراء لكل حكم (ai/intel.py). يتحقق عامل الذكاء الاصطناعي من المؤشرات الموجودة في سجل مقابل AlienVault OTX وVirusTotal. يتطلب OTX_API_KEY / VT_API_KEY؛ عدم تعيينه يعني عدم إجراء أي استدعاء خارجي على الإطلاق.

خلاصات المؤشرات (core/threat_feeds.py). تملأ جدول threat_intel كل ساعة من abuse.ch — Feodo Tracker (عناوين C2 للبوت نت)، ThreatFox (مؤشرات IoCs مختلطة مع درجة ثقة) وURLhaus (عناوين URL الموزعة للبرمجيات الخبيثة).

تحمل المؤشرات last_seen ويتم تقليمها بعد THREAT_INTEL_STALE_DAYS (الافتراضي 30): العنوان الذي استضاف C2 في الربع الماضي عادة ما ينتمي لشخص آخر الآن، والاحتفاظ به ينتج نتائج إيجابية خاطئة إلى أجل غير مسمى. كل خلاصة محدودة بـ THREAT_INTEL_MAX_PER_FEED صفًا لأن الجدول يُقرأ على مسار التنبيه.

كانت abuse.ch تنقل التنزيلات خلف مفتاح حساب مجاني. خلاصة تعيد 401/403 توضح ذلك في سجل الخادم؛ اضبط THREAT_INTEL_AUTH_KEY.

تحقق مما وصل فعليًا:```bash docker logs sentora-server | grep ThreatIntel

مع ضبط هذه الإعدادات، مع ترك OTX_API_KEY / VT_API_KEY غير معيّنة، لا يغادر أي شيء الشبكة. الخطوط مضمّنة، وOllama محلي، ولا يتم الاتصال بأي CDN.

التعرض للأسطول

/api/exposure/report يحسب الحزم غير المصححة وأحداث سلامة الملفات عبر الأسطول، لكل وكيل، من الأسوأ أولاً. وهو يبلّغ عن تغطيته الخاصة: complete: false عندما يتعذر قراءة وكيل، لأن الإجمالي الذي يغطي أكثر من نصف الأسطول ليس إجمالي أسطول.

لا توجد درجة عمداً. كانت نقطة النهاية سابقاً تُرجع 100 - vulns*2 - fim*5 كـ"درجة امتثال" — وهذا لا يطابق أي إطار عمل، ولا يتدرج مع حجم الأسطول، ويُثبَّت عند الصفر على أي أسطول حقيقي. تصنيف الخطورة غائب لنفس السبب: vulnerabilities_report لا يحتوي على عمود خطورة وحقولها مشفّرة عند التخزين، لذا أي تصنيف سيكون مختلقاً.

التحقق من تكوين الوكيل

POST /<agent>/config/<type> يتحقق قبل وصول أي شيء إلى مستشعر: تحليل YAML، والشكل البنيوي، و— الطبقة الأهم — تجميع التعبيرات النمطية. التعبير النمطي غير الصالح هو YAML صالح تماماً ويُعطّل بصمت الفئة التي تحتويه، لذا فحص بناء الجملة فقط سيدفعه مباشرة إلى نقطة النهاية. يقوم المحرر بالفحص اللغوي ضد نفس نقطة النهاية أثناء الكتابة و يُبلّغ عن المشكلات مع أرقام أسطر قابلة للنقر.

نظرة عامة على البنية```

Agent (Win / Linux) │ TCP frames + REST polling ▼ ingest (:5001) ──► RabbitMQ ──► AI worker fleet (3 modes) │ │ ▼ ▼ MySQL (per-agent _db) ai_analysis_results │ ▼ app (Sanic :8000) ──► React UI + REST + WebSocket screen proxy

عمال الذكاء الاصطناعي يدويًا

نفس السكربت، ثلاثة أدوار:```bash WORKER_TYPE=automation python ai_worker.py WORKER_TYPE=manual python ai_worker.py WORKER_TYPE=defensive python ai_worker.py

3. يجب تغليف نقاط النهاية الجديدة بـ @require_permission(...). سجل الإقلاع يطبع العدد الإجمالي؛ إذا أبلغ عن 0 permission-gated، فهناك خطأ في التوصيل، وليس في مسارك.
4. أي شيء يصل إلى وكيل أو مضيف خارجي يحتاج إلى تحقق على جانب الخادم، وليس فقط في المتصفح. تنحرف عمليتا التنفيذ، ونسخة المتصفح هي التي ينتهي الأمر بالمشغلين إلى الوثوق بها.

لأي شيء أكبر من إصلاح، افتح مشكلة أولاً حتى نتمكن من التوافق على النهج.

هيكل المشروع```

. ├── app.py # Sanic API + React SPA host ├── server.py # TCP ingest ├── ai_worker.py # AI worker fleet (3 modes) ├── ai/ │ ├── utils.py # LLM helpers, AI cache, SOAR queueing │ └── intel.py # OTX / VT per-verdict enrichment (opt-in) ├── core/ │ ├── mq.py # RabbitMQ publisher │ ├── opensearch.py # OpenSearch index/search │ ├── config_validation.py # Agent YAML validation (parse, shape, regex) │ └── threat_feeds.py # abuse.ch indicator feeds ├── security/ │ ├── session.py # Server-side session store │ └── ssrf.py # Proxy destination rules ├── scanners/ │ └── vuln.py # Server-side OSV scanner ├── scripts/ │ ├── init_secrets.py # Generate the secrets .env needs │ ├── rotate_db_password.py # Rotate the MySQL root password safely │ └── api_smoke_test.py # Exercise every route against a live server ├── tests/ # pytest; no MySQL or RabbitMQ required ├── frontend/ # React 18 + TS SPA │ └── src/lib/ # Shared logic (playbook action catalogue) ├── Sentora/ # Cross-platform agent ├── certs/ # Self-signed dev certs ├── docs/ # Architecture + screenshots └── docker-compose.yaml