واجهة سطر أوامر/واجهة مستخدم نصية بلغة Python لفرز الأدلة الجنائية لأنظمة Ubuntu — تكتشف آليات الاستمرارية وتعالجها مع جمع الأدلة، وربط الجدول الزمني، وتكامل Wazuh.
تحليل جنائي للأنظمة الحية على Ubuntu — جمع تلقائي للآثار، كشف الاستمرارية، ومعالجة موجّهة في أقل من 5 ثوانٍ.
عندما تشتبه في اختراق نظام Linux، تُقضى أول 30-40 دقيقة عادةً في تشغيل نفس الأوامر العشرة بالتتابع: فحص العمليات الجارية، البحث عن مهام cron غريبة، البحث عن LD_PRELOAD، فحص authorized_keys بحثاً عن مدخلات جديدة، تدقيق sudoers. كل خطوة يدوية، وتتطلب تبديل السياق، وعرضة للخطأ تحت الضغط. إذا فوّت مصدراً واحداً — مثلاً /etc/sudoers.d/ بدلاً من /etc/sudoers فقط، أو crontabs الخاصة بالمستخدمين بالإضافة إلى /etc/cron.d/ — فستحصل على صورة غير مكتملة.
الخيارات الموجودة لا تحل هذه المشكلة بشكل نظيف. lynis هو مدقّق تقوية، وليس أداة تحليل — فهو يبلّغ عن نقاط ضعف التهيئة على نظام نظيف ويولّد ضجيجاً على نظام مصاب. أما chkrootkit وrkhunter فيتحققان من بصمات rootkit المعروفة لكنهما أعمى عن تقنيات الاستمرارية الجديدة مثل مؤقتات systemd المُستغلة أو مدخلات cron التي تبدو شرعية. استعلامات SIEM العامة تتطلب بنية تحتية للسجلات قد لا تكون موجودة على النظام الذي تفحصه. ومجموعات الأدوات الجنائية مثل Volatility تستهدف صور الذاكرة، وليس صدفة حية على مضيف قيد التشغيل.
الفجوة هي أداة تعمل على النظام الحي الآن، وتغطي أكثر نواقل الاستمرارية شيوعاً، وتربط النشاط عبر مصادر السجلات في خط زمني، وتخبرك بالضبط بما يجب النظر إليه — دون الحاجة إلى وكيل خارجي، أو قاعدة بيانات، أو اتصال بالإنترنت.
تعمل ubuntils على أربع مراحل متتابعة:
/proc، وجداول cron، ووحدات systemd، ومفاتيح SSH، وملفات sudoers، وتعريفات البيئة، وسلامة الحزم (dpkg --verify)، وتهيئة PAM/NSS، ووحدات النواة المحمّلة. يستغرق حوالي 2.5 ثانية على نظام نموذجي.--rules — على الآثار المجمّعة، منتجاً قائمة نتائج مرتّبة ومُقيّمة بدرجة ثقة في حوالي ثانية واحدة.--json).لا تُجري ubuntils نفسها أي اتصالات شبكية، وكل ميزة — بما في ذلك القواعد المخصصة والربط — تعمل على الآثار المجمّعة محلياً. الطريقة الوحيدة التي يمكن بها للنتائج مغادرة المضيف هي تكامل Wazuh: إذا كان وكيل Wazuh مثبتاً، فإن scan الحي يكتب نتائجه إلى ملف محلي يقوم الوكيل بعد ذلك بإرساله إلى مديره. مرّر --no-wazuh لإيقاف ذلك خلال التشغيل.
ubuntils scan لم يتغير بفعل كل ما يلي — فهو لا يزال حياً 100%، على مضيف واحد، وكل علامة موجودة تعمل بشكل مطابق. أمران إضافيان، collect وanalyze، يقسّمان نفس خط أنابيب الكشف/الخط الزمني إلى سير عمل مناسب للعمل دون اتصال يقوم بالجمع ثم التحليل، للحالات التي لا تستطيع فيها (أو لا تريد) تشغيل الكشف مباشرة على المضيف قيد التحقيق — انظر التحليل دون اتصال: collect وanalyze أدناه، بما في ذلك تحذيرات تغطية الكشف الخاصة به.
Ubuntu 22.04+ وأي نظام يحتوي على PEP 668 (موصى به):
Ubuntu 22.04+ يحظر pip install على مستوى النظام. استخدم pipx — فهو يتعامل مع البيئة بشفافية بحيث لا تفكر فيها أبداً:```bash
sudo apt install pipx -y
cd ubuntils
pipx install -e .
ubuntils scan
**الأنظمة الأقدم / التثبيت اليدوي:**```bash
git clone https://github.com/asmitdesai/ubuntils.git
cd ubuntils
pip install -r requirements.txt -e .
ubuntils scan
يتطلب ubuntils صلاحيات الجذر للوصول الكامل إلى المخرجات. إذا قمت بتشغيل ubuntils scan كمستخدم غير جذر، فسيقوم تلقائيًا بإعادة استدعاء نفسه باستخدام sudo مع نفس مفسّر Python (عبر المسار المطلق)، بحيث تُستخدم البيئة الصحيحة دون تمرير PATH الخاص بك إلى عملية الجذر. يتم حل كل أمر خارجي (ss، dpkg، systemctl، …) عبر مسار بحث ثابت مملوك للجذر، وليس PATH الخاص بك. سيؤدي التشغيل بدون صلاحيات الجذر إلى تخطي /etc/shadow وبعض مدخلات /proc وملفات cron المحمية، وسيسجّل تحذيرات لكل منها.
الكشف فقط — واجهة TUI تفاعلية:```bash sudo ubuntils scan
**الكشف مع حفظ مخرجات JSON إلى ملف:**```bash
sudo ubuntils scan --json > /tmp/triage-$(hostname)-$(date +%Y%m%d).json
الكشف مع معاينة المعالجة عبر CLI (تشغيل تجريبي — لا يتم تطبيق أي تغييرات):```bash sudo ubuntils scan --remediate
**الكشف مع تطبيق المعالجة عبر CLI:**```bash
sudo ubuntils scan --remediate --confirm
نسخة الطباعة:```bash ubuntils version
**اجمع حزمة مقاومة للتلاعب للتحليل لاحقًا أو دون اتصال:**```bash
sudo ubuntils collect --output /path/to/bundle.tar.gz
تحليل حزمة تم جمعها مسبقًا (لا يتطلب صلاحيات الجذر):```bash ubuntils analyze /path/to/bundle.tar.gz --json
**تحليل صورة جنائية مُثبَّتة أو شجرة نظام ملفات مستخرجة بدلاً من حزمة:**```bash
ubuntils analyze --root /mnt/forensic-image --json
راجع التحليل دون اتصال: الجمع والتحليل للاطلاع على تنسيق الحزمة، والأهم من ذلك، ما لا يمكن للتحليل دون اتصال اكتشافه مقارنةً بـ scan المباشر.
ubuntils scan [OPTIONS] --json Output JSON to stdout instead of launching the TUI --output FILE Write the JSON report to FILE (implies --json) --remediate Run the remediation engine after detection --confirm Required with --remediate to actually apply changes (else dry-run) --min-confidence N Only auto-remediate findings with confidence >= N (default 40) --no-wazuh Never forward findings to a local Wazuh agent --config FILE YAML allowlist of findings to suppress (see below) --baseline FILE YAML baseline of environment-specific known-good fingerprints to suppress (see below) --since TIME Limit the timeline to events since TIME (e.g. '24h', '7d', '2026-05-20') --rules FILE YAML file of custom detection rules to add (see below) --verbose Verbose structlog output
ubuntils collect [OPTIONS] --output FILE Bundle path to write (default ./ubuntils-bundle-.tar.gz) --verbose Verbose structlog output
ubuntils analyze (BUNDLE | --root PATH) [OPTIONS] --root PATH Analyze a mounted image / artifact tree instead of a bundle --json Output JSON instead of launching the TUI --output FILE Write the JSON report to FILE (implies --json) --config FILE YAML allowlist of findings to suppress (same format as scan) --baseline FILE YAML baseline of environment-specific known-good fingerprints to suppress (same format as scan) --rules FILE YAML file of custom detection rules to add (same format as scan) --since TIME Limit the timeline to events since TIME (e.g. '24h', '7d', '2026-05-20') --verbose Verbose structlog output
ubuntils version Print version string and exit
### القائمة البيضاء للإيجابيات الكاذبة (`--config`)
مضيف تم تزويده حديثًا أو يُدار عبر CI يولّد ضجيجًا متوقعًا — مفاتيح النشر، مهام cron الخاصة بالتزويد، تهيئة shell المدمجة. بدلًا من تعليم المستجيبين تصفية ذلك ذهنيًا، قم بكتمه صراحةً عبر قائمة بيضاء بصيغة YAML:```yaml
# allowlist.yaml
allowlist:
rules:
- SHELL_RC_MODIFICATION # suppress this rule entirely
paths:
- /home/ci/.ssh/authorized_keys # suppress any finding on this exact path
python3 -m pip install -r requirements.txt
python3 -m pip install .
python3 -m pip install -r docs/requirements.txt
cd docs
sphinx-build -M html . _build
python3 -m pip install -r tests/requirements.txt
python3 -m pytest tests
docker build -t cve-bin-tool .
docker run -v $(pwd):/cve-bin-tool cve-bin-tool python3 -m pytest tests
docker-compose build
docker-compose run --rm cve-bin-tool python3 -m pytest tests
vagrant up
vagrant ssh
cd /vagrant
python3 -m pytest tests
gh workflow run test.yml
make test
python3 -m pip install tox
tox
python3 -m pip install nox
nox
python3 -m pip install pre-commit
pre-commit run --all-files
python3 -m pip install black
black .
python3 -m pip install flake8
flake8 .
python3 -m pip install isort
isort .
python3 -m pip install mypy
mypy .
python3 -m pip install pylint
pylint cve_bin_tool
python3 -m pip install bandit
bandit -r cve_bin_tool
python3 -m pip install safety
safety check
python3 -m pip install pip-audit
pip-audit
python3 -m pip install semgrep
semgrep --config=auto
docker run --rm -v $(pwd):/cve-bin-tool aquasec/trivy fs /cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/grype dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/syft dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool snyk/snyk-cli test
docker run --rm -v $(pwd):/cve-bin-tool owasp/dependency-check --scan /cve-bin-tool
python3 -m cve_bin_tool.cli --help
docker run --rm -v $(pwd):/cve-bin-tool cve-bin-tool --help
docker-compose run --rm cve-bin-tool --help
vagrant up
vagrant ssh
cd /vagrant
python3 -m cve_bin_tool.cli --help
gh workflow run cve-bin-tool.yml
make cve-bin-tool
python3 -m pip install tox
tox -e cve-bin-tool
python3 -m pip install nox
nox -s cve-bin-tool
python3 -m pip install pre-commit
pre-commit run --all-files
python3 -m pip install black
black .
python3 -m pip install flake8
flake8 .
python3 -m pip install isort
isort .
python3 -m pip install mypy
mypy .
python3 -m pip install pylint
pylint cve_bin_tool
python3 -m pip install bandit
bandit -r cve_bin_tool
python3 -m pip install safety
safety check
python3 -m pip install pip-audit
pip-audit
python3 -m pip install semgrep
semgrep --config=auto
docker run --rm -v $(pwd):/cve-bin-tool aquasec/trivy fs /cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/grype dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/syft dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool snyk/snyk-cli test
docker run --rm -v $(pwd):/cve-bin-tool owasp/dependency-check --scan /cve-bin-tool
python3 -m cve_bin_tool.cli --help
docker run --rm -v $(pwd):/cve-bin-tool cve-bin-tool --help
docker-compose run --rm cve-bin-tool --help
vagrant up
vagrant ssh
cd /vagrant
python3 -m cve_bin_tool.cli --help
gh workflow run cve-bin-tool.yml
make cve-bin-tool
python3 -m pip install tox
tox -e cve-bin-tool
python3 -m pip install nox
nox -s cve-bin-tool
python3 -m pip install pre-commit
pre-commit run --all-files
python3 -m pip install black
black .
python3 -m pip install flake8
flake8 .
python3 -m pip install isort
isort .
python3 -m pip install mypy
mypy .
python3 -m pip install pylint
pylint cve_bin_tool
python3 -m pip install bandit
bandit -r cve_bin_tool
python3 -m pip install safety
safety check
python3 -m pip install pip-audit
pip-audit
python3 -m pip install semgrep
semgrep --config=auto
docker run --rm -v $(pwd):/cve-bin-tool aquasec/trivy fs /cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/grype dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/syft dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool snyk/snyk-cli test
docker run --rm -v $(pwd):/cve-bin-tool owasp/dependency-check --scan /cve-bin-tool
python3 -m cve_bin_tool.cli --help
docker run --rm -v $(pwd):/cve-bin-tool cve-bin-tool --help
docker-compose run --rm cve-bin-tool --help
vagrant up
vagrant ssh
cd /vagrant
python3 -m cve_bin_tool.cli --help
gh workflow run cve-bin-tool.yml
make cve-bin-tool
python3 -m pip install tox
tox -e cve-bin-tool
python3 -m pip install nox
nox -s cve-bin-tool
python3 -m pip install pre-commit
pre-commit run --all-files
python3 -m pip install black
black .
python3 -m pip install flake8
flake8 .
python3 -m pip install isort
isort .
python3 -m pip install mypy
mypy .
python3 -m pip install pylint
pylint cve_bin_tool
python3 -m pip install bandit
bandit -r cve_bin_tool
python3 -m pip install safety
safety check
python3 -m pip install pip-audit
pip-audit
python3 -m pip install semgrep
semgrep --config=auto
docker run --rm -v $(pwd):/cve-bin-tool aquasec/trivy fs /cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/grype dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/syft dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool snyk/snyk-cli test
docker run --rm -v $(pwd):/cve-bin-tool owasp/dependency-check --scan /cve-bin-tool
python3 -m cve_bin_tool.cli --help
docker run --rm -v $(pwd):/cve-bin-tool cve-bin-tool --help
docker-compose run --rm cve-bin-tool --help
vagrant up
vagrant ssh
cd /vagrant
python3 -m cve_bin_tool.cli --help
gh workflow run cve-bin-tool.yml
make cve-bin-tool
python3 -m pip install tox
tox -e cve-bin-tool
python3 -m pip install nox
nox -s cve-bin-tool
python3 -m pip install pre-commit
pre-commit run --all-files
python3 -m pip install black
black .
python3 -m pip install flake8
flake8 .
python3 -m pip install isort
isort .
python3 -m pip install mypy
mypy .
python3 -m pip install pylint
pylint cve_bin_tool
python3 -m pip install bandit
bandit -r cve_bin_tool
python3 -m pip install safety
safety check
python3 -m pip install pip-audit
pip-audit
python3 -m pip install semgrep
semgrep --config=auto
docker run --rm -v $(pwd):/cve-bin-tool aquasec/trivy fs /cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/grype dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/syft dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool snyk/snyk-cli test
docker run --rm -v $(pwd):/cve-bin-tool owasp/dependency-check --scan /cve-bin-tool
python3 -m cve_bin_tool.cli --help
docker run --rm -v $(pwd):/cve-bin-tool cve-bin-tool --help
docker-compose run --rm cve-bin-tool --help
vagrant up
vagrant ssh
cd /vagrant
python3 -m cve_bin_tool.cli --help
gh workflow run cve-bin-tool.yml
make cve-bin-tool
python3 -m pip install tox
tox -e cve-bin-tool
python3 -m pip install nox
nox -s cve-bin-tool
python3 -m pip install pre-commit
pre-commit run --all-files
python3 -m pip install black
black .
python3 -m pip install flake8
flake8 .
python3 -m pip install isort
isort .
python3 -m pip install mypy
mypy .
python3 -m pip install pylint
pylint cve_bin_tool
python3 -m pip install bandit
bandit -r cve_bin_tool
python3 -m pip install safety
safety check
python3 -m pip install pip-audit
pip-audit
python3 -m pip install semgrep
semgrep --config=auto
docker run --rm -v $(pwd):/cve-bin-tool aquasec/trivy fs /cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/grype dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/syft dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool snyk/snyk-cli test
docker run --rm -v $(pwd):/cve-bin-tool owasp/dependency-check --scan /cve-bin-tool
python3 -m cve_bin_tool.cli --help
docker run --rm -v $(pwd):/cve-bin-tool cve-bin-tool --help
docker-compose run --rm cve-bin-tool --help
vagrant up
vagrant ssh
cd /vagrant
python3 -m cve_bin_tool.cli --help
gh workflow run cve-bin-tool.yml
make cve-bin-tool
python3 -m pip install tox
tox -e cve-bin-tool
python3 -m pip install nox
nox -s cve-bin-tool
python3 -m pip install pre-commit
pre-commit run --all-files
python3 -m pip install black
black .
python3 -m pip install flake8
flake8 .
python3 -m pip install isort
isort .
python3 -m pip install mypy
mypy .
python3 -m pip install pylint
pylint cve_bin_tool
python3 -m pip install bandit
bandit -r cve_bin_tool
python3 -m pip install safety
safety check
python3 -m pip install pip-audit
pip-audit
python3 -m pip install semgrep
semgrep --config=auto
docker run --rm -v $(pwd):/cve-bin-tool aquasec/trivy fs /cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/grype dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool anchore/syft dir:/cve-bin-tool
docker run --rm -v $(pwd):/cve-bin-tool snyk/snyk-cli test
docker```bash
sudo ubuntils scan --json --config allowlist.yaml
يتم التثبيط دائمًا بشكل صريح — بواسطة معرّف القاعدة و/أو مسار الأثر الدقيق. لا يوجد مفتاح شامل "تجاهل كل شيء". توجد عينة في examples/allowlist.yaml.
--baseline)يقوم --config بتثبيط قاعدة أو مسار في كل مكان، لأي شخص يشغّل ubuntils على قاعدة الشيفرة هذه. أما --baseline فهو أضيق وأكثر ارتباطًا بالبيئة: فهو يقول "في هذه البيئة، هذا الأثر الدقيق — هذا مفتاح SSH، هذا الملف RC — معروف جيدًا"، دون كتم القاعدة أو المسار لكل مضيف آخر تفحصه بنفس الأداة. يُحفظ كملف منفصل عن --config لنفس السبب الذي يجعل --rules منفصلًا: فالتثبيط والقوائم المسموح بها على مستوى القاعدة هما أمران مختلفان لا ينبغي أن يوجدا في ملف واحد.```yaml
baseline:
## الاستخدام
python3 CVE-2025-55182.py -u -c
### المعاملات
| المعامل | الوصف |
|-----------|-------------|
| `-u, --url` | عنوان URL الهدف (مطلوب) |
| `-c, --cmd` | الأمر المراد تنفيذه (مطلوب) |
| `-t, --timeout` | مهلة الطلب بالثواني (افتراضي: 10) |
| `-v, --verbose` | تفعيل الإخراج المطوّل |
### أمثلة
```bash
# Basic command execution
python3 CVE-2025-55182.py -u http://target.com -c "id"
# Read a file
python3 CVE-2025-55182.py -u http://target.com -c "cat /etc/passwd"
# With custom timeout
python3 CVE-2025-55182.py -u http://target.com -c "whoami" -t 30
# Verbose mode
python3 CVE-2025-55182.py -u http://target.com -c "ls -la" -v
يستغل هذا الأداة ثغرة CVE-2025-55182، وهي ثغرة تنفيذ أوامر عن بُعد (RCE) في React Server Components. تتضمن سلسلة الاستغلال:
requestspip install requests
لأغراض تعليمية واختبار الاختراق المصرح به فقط.
هذه الأداة مخصصة لاختبار الاختراق الأخلاقي والبحث الأمني. يجب عليك:
المؤلفون غير مسؤولين عن أي سوء استخدام أو أضرار ناتجة عن هذه الأداة.
هذا المشروع مرخص بموجب ترخيص MIT - راجع ملف LICENSE للحصول على التفاصيل.
تنبيه: استخدم هذه الأداة بمسؤولية وأخلاقية. الهدف هو تحسين الأمن، وليس استغلاله.```bash sudo ubuntils scan --json --baseline baseline.yaml
مُدخل خط الأساس يطابق عبر `rule_id` بالإضافة إلى `fingerprint` الذي يُختبر كسلسلة فرعية من `raw_value` الخاص بالنتيجة أو مطابقة تامة مقابل `artifact_path` الخاص بها. المطابقة تُسقط النتيجة من التقرير بالكامل — لكن الكبت لا يكون صامتًا أبدًا: عدد النتائج التي أزالها خط الأساس يظل مرئيًا دائمًا في `scan_metadata.suppressed_by_baseline`. كبت قائمة السماح (`--config`) لا يزال يُطبَّق فوق كبت خط الأساس. يعمل بشكل متطابق على `scan` و`analyze`. يوجد نموذج في [`examples/baseline.yaml`](https://github.com/asmitdesai/ubuntils/blob/main/examples/baseline.yaml).
### قواعد الكشف المخصصة (`--rules`)
`--config` *يكبت* النتائج؛ `--rules` *يضيفها*. هما ملفان منفصلان عمدًا لأنهما شأنان متعاكسان.
ملف القواعد يعتمد على مطابقة الأنماط فقط — لا تعبيرات، ولا شروط، ولا تنفيذ كود، لذا فإن تحميله لا يمكن أن يشغّل منطقًا مقدَّمًا من المهاجم. كل قاعدة تُسمّي `source` الخاص بالأثر، ووضع `match`، و`pattern`:```yaml
# custom_rules.yaml
rules:
- id: CUSTOM_KNOWN_MINER
severity: HIGH # HIGH | MEDIUM | LOW
title: Known cryptominer in process cmdline
description: A running process command line matches a known miner.
source: process # cron | environment | ssh | process | network
match: substring # regex | substring | glob
pattern: xmrig
Kitploit هو دليل مخصص لأدوات الأمن السيبراني مفتوحة المصدر. يقدم مجموعة منسقة من أدوات الاختراق الأخلاقي، وتحليل الثغرات الأمنية، والاستجابة للحوادث، والاختبار الأمني، مما يسهل على المتخصصين اكتشاف الأدوات المناسبة لاحتياجاتهم الأمنية.
لتصفح الأدوات، قم بزيارة موقع Kitploit واختر فئة أو استخدم وظيفة البحث للعثور على أدوات محددة.
للمساهمة في Kitploit، يمكنك:
جميع الأدوات المدرجة في Kitploit تخضع لتراخيصها الخاصة. يرجى الرجوع إلى وثائق كل أداة للحصول على معلومات الترخيص.```bash sudo ubuntils scan --json --rules custom_rules.yaml
| `source` | يُطابَق مقابل |
|---|---|
| `cron` | أمر cron (المسار: ملف crontab) |
| `environment` | سطر البيئة/تهيئة الصدفة الخام (المسار: الملف المُعرِّف) |
| `ssh` | نوع المفتاح، وبيانات المفتاح، والتعليق (المسار: ملف `authorized_keys`) |
| `process` | سطر أوامر العملية (المسار: مسار الملف التنفيذي) |
| `network` | وصف الاتصال (المسار: `remote_addr:remote_port`) |
يطابق `regex` و`substring` عمود النص؛ بينما يطابق `glob` عمود المسار — لذا فإن `glob` الخاص بـ `network` مثل `203.0.113.*:*` يستهدف نقطة النهاية البعيدة. نتائج القواعد المخصصة هي للإشارة فقط (لا تُعالَج تلقائيًا أبدًا) ولا تزال خاضعة لكتم `--config`. توجد عينة في [`examples/custom_rules.yaml`](https://github.com/asmitdesai/ubuntils/blob/main/examples/custom_rules.yaml).
### سلامة التقرير
يحمل كل تقرير `--json` حقل `report_sha256` — وهو SHA-256 على محتوى التقرير القانوني. وهذا يجعل أثر الفرز المُجمَّع مقاومًا للتلاعب ويتيح لك الإشارة إلى فحص معين بواسطة البصمة في ملف القضية. كما يسجّل التقرير `tool_version` و`hostname` وطابعًا زمنيًا `generated_at` بتوقيت UTC ضمن `scan_metadata`. بالنسبة إلى `scan`، يصف `hostname`/`ubuntu_version` الجهاز الذي يعمل عليه `ubuntils`؛ وبالنسبة إلى `analyze --root` يُقرآن من `/etc/hostname` و`/etc/os-release` الخاصين بالصورة نفسها. أما بالنسبة إلى `analyze BUNDLE`، فيأتيان بدلًا من ذلك من بيان الحزمة نفسه — المضيف الذي تم *جمعه*، وليس المضيف الذي يشغّل `analyze` — إلى جانب `collection_run_id` و`collected_at_utc_start`/`collected_at_utc_end` الخاصين بالجمع، بحيث يتبع سجل سلسلة الحيازة الخاص بالتقرير الأدلة بدلًا من محطة عمل المحلل.
**التحقق من تقرير.** يُصدَر التقرير بصيغة قانونية (مفاتيح مرتبة، وإزاحة بمقدار مسافتين)، وتغطي البصمة كل شيء باستثناء `report_sha256` نفسه:```python
import hashlib, json
doc = json.load(open("report.json"))
claimed = doc.pop("report_sha256")
assert hashlib.sha256(json.dumps(doc, indent=2, sort_keys=True).encode()).hexdigest() == claimed
يشغّل ubuntils scan عمليات الجمع والكشف والخط الزمني معًا على المضيف المباشر. أما collect وanalyze فيقسّمان هذا المسار إلى قسمين: collect يحصل على حزمة مقاومة للتلاعب من مضيف (دون تشغيل أي كشف)، وanalyze يشغّل نفس مسار الكشف/الخط الزمني الذي يستخدمه scan على حزمة، أو على صورة مُثبَّتة عبر --root، دون الحاجة إلى صلاحيات الجذر ودون لمس المضيف الأصلي مرة أخرى. هذا مخصص للحالات التي تريد فيها جمع الآثار مرة واحدة وتحليلها لاحقًا، أو في مكان آخر، أو بشكل متكرر — أو عندما تفحص صورة قرص بدلًا من نظام قيد التشغيل.
sudo ubuntils collect --output /path/to/bundle.tar.gz
يتطلب صلاحيات الجذر، مثل `scan`. يقرأ قائمة ثابتة من الملفات (`/etc/passwd`، `/etc/group`، `/etc/shadow`، `/etc/sudoers`، `/etc/ld.so.preload`، `/etc/environment`، `/etc/crontab`، `/etc/profile`، `/var/log/syslog`، `/var/log/messages`، `/var/log/audit/audit.log`) وينفّذ قائمة ثابتة من الأوامر (`ss -tunap`، `netstat -tunap`، `systemctl list-timers` بصيغتي JSON والنص، و`journalctl -o json` لآخر 7 أيام)، ويحسب تجزئة لكل عنصر مُلتقط، ويكتب كل شيء بالإضافة إلى `manifest.json` داخل حزمة `.tar.gz`. ملفات السجل المُلتقطة ومخرجات journalctl هي ما يمكّن `analyze BUNDLE` من بناء خط زمني حقيقي دون اتصال. إذا تم حذف `--output`، تُكتب الحزمة إلى `./ubuntils-bundle-<UTC timestamp>.tar.gz` في الدليل الحالي.
### `ubuntils analyze````bash
ubuntils analyze BUNDLE.tar.gz [--json] [--output FILE] [--config FILE] [--baseline FILE] [--rules FILE] [--since TIME]
ubuntils analyze --root /mnt/forensic-image [--json] [--output FILE] [--config FILE] [--baseline FILE] [--rules FILE] [--since TIME]
يأخذ إما مسار حزمة كوسيطة موضعية أو --root PATH يشير إلى صورة مُثبَّتة / شجرة نظام ملفات مستخرجة — وليس كليهما. يشغّل محرك الكشف نفسه، والقواعد المخصصة، وقائمة السماح، ومنطق خط الأساس المستخدم بواسطة scan. لا يتطلب صلاحيات root. تُستخرج الحزمة إلى دليل مؤقت خاص يُحذف بمجرد انتهاء التحليل (قد يحتوي على /etc/shadow).
تختلف التغطية بين وضعي العمل دون اتصال، لأن الحزمة تحمل حالة مُعاد تشغيلها ملتقطة من وقت collect بينما --root لا يملك سوى ما هو موجود على نظام الملفات المُثبَّت:
analyze BUNDLE يعيد تشغيل مخرجات الأوامر الحقيقية ss/systemctl list-timers/journalctl الملتقطة في وقت collect، لذا يُنتج NetworkCollector وSystemdCollector نتائج حقيقية من تلك اللقطة — ولا يتم تخطيهما. يُبنى الخط الزمني من syslog/messages/audit.log/journalctl التي التقطتها الحزمة، لذا يكون ممتلئًا بالكامل وتحصل النتائج على ارتباط related_events حقيقي.analyze --root PATH يشير إلى صورة ميتة مُثبَّتة بدون حالة عملية حية أو حالة نواة للاستعلام عنها، لذا يتم تعطيل تنفيذ الأوامر بالكامل: يتم تخطي NetworkCollector وSystemdCollector، ويُسجَّل ذلك في scan_metadata.command_collectors_skipped. لا يزال الخط الزمني يُبنى، ولكن من ملفات السجل الثابتة الموجودة على الصورة (، ، ) — إعادة تشغيل journald غير متاحة هنا لأنه لا يوجد حي للاستعلام عن صورة ميتة.راجع التحليل دون اتصال: collect وanalyze للحصول على القائمة الكاملة لثغرات تغطية الكشف دون اتصال.
الحزمة عبارة عن tarball مضغوط بـ gzip مع كل شيء تحت بادئة bundle/:```
bundle/
├── manifest.json
├── files/
│ ├── etc/passwd
│ ├── etc/shadow
│ ├── var/log/syslog
│ └── ... # every captured file, path-flattened under files/
└── commands/
├── ss.txt
├── netstat.txt
├── systemctl_list_timers_json.txt
├── systemctl_list_timers_text.txt
└── journalctl.txt
مخطط `manifest.json`:
| الحقل | النوع | الوصف |
|---|---|---|
| `run_id` | string | UUID يُولَّد من جديد لكل تشغيل `collect` |
| `host_id` | string | محجوز للربط المستقبلي متعدد المضيفين؛ فارغ حالياً |
| `hostname` | string | `socket.gethostname()` في وقت الجمع |
| `ubuntu_version` | string | سلسلة إصدار Ubuntu المكتشفة |
| `collected_at_utc_start` / `collected_at_utc_end` | string (ISO 8601) | حدود الوقت الفعلي لتشغيل الجمع |
| `tool_version` | string | إصدار ubuntils الذي أنتج الحزمة |
| `files[]` | array | مدخل واحد لكل ملف مُلتقط: `source_path`، `bundle_path`، `sha256`، `size`، `mtime`، `ctime` (الملف الغائب/غير القابل للقراءة على المضيف المصدر يُسجَّل بـ `sha256: ""`، `size: -1` بدلاً من إجهاض الجمع) |
| `commands[]` | array | مدخل واحد لكل أمر مُلتقط: `name`، `argv`، `bundle_path`، `sha256`، `exit_code` |
| `bundle_sha256` | string | SHA-256 على بقية المخطط (كل ما سبق، بتسلسل قانوني) — مرتكز إثبات العبث للحزمة بأكملها |
### سلامة الحزمة في مخرجات JSON
يُبلِّغ `scan_metadata.bundle_integrity` في `analyze` عن إحدى ثلاث قيم:
- `"live"` — يُبلِّغ `scan` و `analyze --root` بهذه القيمة؛ لا توجد حزمة للتحقق منها.
- `"ok"` — تحقَّق `analyze BUNDLE` من `bundle_sha256` مقابل المخطط ومن SHA-256 لكل ملف مُلتقط مقابل محتواه في الحزمة؛ لم يُعدَّل شيء منذ أن كتبه `collect`.
- `"mismatch"` — لم يتطابق ملخّص المخطط، أو تجزئة ملف مُلتقط، أو تجزئة مخرجات أمر مُلتقط. عُدِّل شيء في الحزمة أو اقتُطع أو تلف بعد الجمع، ولا ينبغي الوثوق بأي شيء مشتق منها باعتباره نظيفاً من حيث سلسلة الحيازة. لا يزال `analyze` ينتج تقريره، لكنه يطبع تحذيراً أحمر إلى stderr، ويعرض شريط سلامة في أعلى تبويب Summary في TUI، و**يخرج بالحالة 3**، حتى لا تخطئ السكربتات في اعتبار نتائج حزمة مُتلاعب بها نتائج موثوقة.
### ⚠️ للتحليل دون اتصال ثغرات كشف حقيقية — اقرأ هذا قبل الاعتماد عليه
**تشغيل `analyze` المصدره حزمة أو `--root` لا يمتلك تكافؤاً في الكشف مع `scan` الحي.** هذه ليست حالات حافة؛ بل قيود بنيوية للاستحواذ الساكن دون اتصال، وهي تنتج نتائج أقل (أو صفرية) للقواعد المتأثرة بدلاً من خطأ. حيث *يعلم* المجمِّع أنه لم يستطع النظر (أمر فاشل، ملف غير قابل للقراءة)، يُسجَّل ذلك في `scan_metadata.collectors_degraded` ويُعلَّم في تبويب Summary في TUI — لكن ملفاً لم يُلتقط ببساطة يبدو كملف غير موجود. (الخط الزمني نفسه *لم يعد* أحد هذه الثغرات: يعيد `analyze BUNDLE` تشغيل syslog/messages/audit.log/journalctl المُلتقطة من وقت `collect`، ويقرأ `analyze --root` ملفات السجل الساكنة الموجودة على الصورة المُثبَّتة، لذا ينتج كلاهما خطاً زمنياً حقيقياً وربطاً حقيقياً لـ `related_events` — انظر [`ubuntils analyze`](#ubuntils-analyze) أعلاه.)
- **`PROCESS_MASQUERADE` و `PROCESS_SUSPICIOUS_CONNECTION` سيُبلِّغان دائماً بصفر نتائج في الوضع دون اتصال.** تستند كلتا القاعدتين إلى حقل `exe` الخاص بالعملية، الذي يُملأ بقراءة هدف الرابط الرمزي `/proc/<pid>/exe` عبر مصدر الأثر (وليس `/proc` الخاص بالمحلل أبداً). لا تملك الحزمة `/proc` حياً لقراءته، ويشير `--root` إلى شجرة نظام ملفات مُثبَّتة بلا `/proc` أيضاً — لا توجد حالياً آلية لالتقاط أو إعادة بناء هدف رابط exe الرمزي المُحلَّل دون اتصال، لذا يكون `exe` فارغاً دائماً ولا تنطلق القاعدتان أبداً، بغض النظر عما هو موجود فعلاً على المضيف.
- **لا يحدث تعداد العمليات إطلاقاً دون اتصال.** لا تملك `collect` خطوة التقاط لكل PID (`/proc/*/status`، `/proc/*/cmdline`)، لذا لا توجد عمليات في الحزمة لتحليلها من الأساس — هذا هو السبب الجذري نفسه للنقطة أعلاه، من جانب الاستحواذ.
- **`CRON_TMP_PATH` و `SUDOERS_NOPASSWD` و `SSH_UNAUTHORIZED_KEY` محدودة أو غائبة من التحليل المصدره حزمة.** قائمة ملفات `collect` ساكنة ولا يمكنها توسيع glob لـ `/etc/cron.d/*`، `/etc/sudoers.d/*`، `/etc/profile.d/*`، أو `~/.ssh/authorized_keys` لكل مستخدم — يُلتقط فقط `/etc/crontab`، `/etc/sudoers`، و `/etc/environment`/`/etc/profile`. (`--root` مقابل شجرة نظام ملفات مُثبَّتة كاملة لا يعاني من هذه الثغرة، لأن الأدلة الحقيقية موجودة على القرص.) عندما *تنطلق* `SSH_UNAUTHORIZED_KEY` أو `SHELL_RC_MODIFICATION` (فحص حي، أو `--root` مع أدلة المستخدمين الحقيقية موجودة)، فإنها الآن تحتسب الثقة أيضاً من ctime ومحتوى الملف، وليس من mtime وحده — انظر [تقييم الثقة](#json-output) أدناه. هذا يحسِّن مقدار ما ينبغي أن تثق به في نتيجة تنطلق فعلاً؛ لكنه لا يغيّر ما إذا كانت القاعدة تنطلق دون اتصال من الأساس.
- **كشف `SUSPICIOUS_SYSTEMD_TIMER` مُضعَّف بالنسبة للحزم.** تُقرأ وحدات الخدمة مباشرة من أدلة الوحدات (`/etc/systemd/system`، `/usr/lib/systemd/system`، `~/.config/systemd/user` لكل مستخدم، …)، لذا يحصل `--root` على تغطية كاملة للخدمات. لكن الحزمة لا تلتقط تلك الأدلة: تظهر المؤقتات من مخرجات `systemctl list-timers` المُلتقطة، لكن `ExecStart` لكل مؤقت يأتي من استدعاء `systemctl show` لكل وحدة لا تقوم به `collect`، لذا لا تستطيع القاعدة تقييم ما يشغّله مؤقت داخل حزمة.
**متى يهم هذا:** إذا كنت تفحص مضيفاً حياً قابلاً للوصول، استخدم `sudo ubuntils scan` — فهو يمتلك تغطية كشف كاملة. استخدم `collect`/`analyze` عندما تحتاج إلى الاستحواذ مرة واحدة والتحليل في مكان آخر، أو تحتاج إلى التحليل دون صلاحيات root، أو تعمل من صورة قرص حيث لا يكون `scan` خياراً على الإطلاق — وتعامل مع نتيجة `analyze` نظيفة للقواعد أعلاه على أنها "لم تُفحص"، وليس "فُحصت ونظيفة".
---
## واجهة TUI
تشغيل `sudo ubuntils scan` (بدون `--json`) يُطلق واجهة TUI تفاعلية بملء الطرفية.
### شاشة الفحص
أثناء تشغيل المجمِّعات، يعرض ubuntils قائمة تحقق حية — صف واحد لكل مجمِّع. يُحدَّث كل صف في الوقت الفعلي عند انتهاء المجمِّع:```
Scanning system…
✓ Process
✓ Network
✓ Users
⠹ Cron
Systemd
SSH
Sudoers
Environment
✓ تشير إلى النجاح، و✗ تشير إلى الفشل، وتشير مؤشر الدوران إلى المجمّع النشط، والصفوف الفارغة قيد الانتظار. بمجرد انتهاء جميع المجمّعات واكتمال الكشف + الجدول الزمني، تنتقل واجهة TUI تلقائيًا إلى شاشة النتائج.
تحتوي شاشة النتائج على أربع علامات تبويب يتم التنقل بينها بمفاتيح الأرقام:
اضغط q أو Ctrl+C للخروج.
1)تعرض بيانات الفحص الوصفية وأهم النتائج على شاشة واحدة:``` Collectors: 8 run · 0 failed Findings: 2 HIGH · 1 MEDIUM · 0 LOW Timeline: 47 events Duration: 2.8s
● HIGH CRON_TMP_PATH /etc/cron.d/cleanup ● HIGH LD_PRELOAD_INJECT /home/alice/.bashrc ○ MED SSH_UNAUTHORIZED_KEY /home/bob/.ssh/authorized_keys
على نظام نظيف، يعرض هذا التبويب `System appears clean.`
### تبويب النتائج (المفتاح `2`)
قائمة قابلة للتمرير بجميع النتائج، مرتبة من HIGH → MEDIUM → LOW. عند تحديد نتيجة (Enter أو مفاتيح الأسهم) يتم توسيع جزء التفاصيل في الأسفل يعرض الوصف الكامل، ومسار الأثر، والقيمة الأولية المسببة، ومعلومات المعالجة.```
HIGH CRON_TMP_PATH /etc/cron.d/cleanup
HIGH LD_PRELOAD_INJECT /home/alice/.bashrc
MED SSH_UNAUTHORIZED_KEY /home/bob/.ssh/authorized_keys
───────────────────────────────────────────────────────
A cron job was found referencing /tmp, /var/tmp, or /dev/shm.
These directories are world-writable and commonly used as
attacker staging grounds.
Artifact: /etc/cron.d/cleanup
Raw: 0 * * * * root /tmp/.update
Fix: Will remove the offending cron entry from
/etc/cron.d/cleanup after creating a timestamped backup.
R: remediate
بالنسبة للنتائج التي تتوفر لها معالجة آلية، اضغط على R أثناء تحديد النتيجة. تظهر نافذة تأكيد:```
┌─────────────────────────────────────────────────┐
│ Remediate CRON_TMP_PATH? │
│ │
│ Will remove the offending cron entry from │
│ /etc/cron.d/cleanup after creating a backup. │
│ Backup will be created at /var/backups/ubuntils/…│
│ │
│ Y: confirm Esc: cancel │
└─────────────────────────────────────────────────┘
اضغط `Y` للتأكيد. يعمل المُعالج في خيط خلفي. عند اكتماله، يتم تحديث صف النتيجة في القائمة إلى `[fixed]` ويعرض جزء التفاصيل النتيجة:```
✓ Remediated
Backup: /var/backups/ubuntils/20260115_142201/etc_cron.d_cleanup
Rollback: cp /var/backups/ubuntils/20260115_142201/etc_cron.d_cleanup /etc/cron.d/cleanup
عند الفشل، يعرض جزء التفاصيل الخطأ. يتم إنشاء النسخة الاحتياطية دائمًا قبل محاولة أي تغيير.
اضغط على Esc لطي جزء التفاصيل.
3)قائمة زمنية قابلة للتمرير لأحداث السجل المترابطة. يعرض كل صف الطابع الزمني والمصدر والوصف. يتم سحب الأحداث من syslog وjournald وauditd وإزالة التكرارات.
4)عرض ملخص للفحص: إصدار Ubuntu المكتشف، والبنية المعمارية، ومدة الفحص، وعدد أدوات الجمع والإخفاقات، وعدد النتائج لكل مستوى خطورة إلى جانب إجمالي أحداث الجدول الزمني.
CRON_ROOT_EXEC — تعمل مهام cron للمستخدمين باسم مالك crontab. إدخال يستدعي sudo أو مفسّرًا مملوكًا للجذر يعني أن المستخدم قد رتّب لتشغيل كود بامتيازات الجذر وفق جدول زمني، دون الحاجة إلى وصول sudo دائم. هذا يبقى حتى بعد تغيير كلمات المرور.
مثال على نتيجة:``` [HIGH] CRON_ROOT_EXEC Title: User crontab executing with sudo Artifact: /var/spool/cron/crontabs/alice Raw value: */5 * * * * sudo /usr/bin/python3 /tmp/beacon.py Remediation: available
**CRON_TMP_PATH** — تُعدّ المجلدات القابلة للكتابة من قبل الجميع مثل /tmp و/dev/shm أرضيات تجهيز قياسية للمهاجمين. وجود مهمة cron تشير إلى هناك يعني أنه يمكن استبدال الحمولة بين الاستدعاءات دون لمس أي مسار دائم. يغطي هذا إدخالات بنمط `@reboot`/`@daily` والسكربتات في `/etc/cron.{hourly,daily,weekly,monthly}`؛ النتائج على تلك السكربتات تكون للإشارة فقط، لأن حذف سطر واحد من سكربت shell ليس إصلاحًا تلقائيًا آمنًا.
*مثال على النتيجة:*```
[HIGH] CRON_TMP_PATH
Title: Cron job references writable temp directory
Artifact: /etc/cron.d/cleanup
Raw value: 0 * * * * root /tmp/.update
Remediation: available
LD_PRELOAD_INJECT — يتسبب LD_PRELOAD في قيام الرابط الديناميكي بتحميل مكتبة مشتركة محددة قبل جميع المكتبات الأخرى، مما يسمح باعتراض الدوال بشكل تعسفي في أي ملف ثنائي مرتبط ديناميكيًا. تشير قيمة تشير إلى خارج مسارات المكتبات القياسية إلى مؤشر شبه مؤكد على وجود روتكيت في مساحة المستخدم؛ يتم فحص كل مكتبة في قائمة مفصولة بمسافة أو نقطتين. يحقن /etc/ld.so.preload في كل عملية ويكون فارغًا في Ubuntu الأصلي، لذا يتم الإبلاغ عن أي إدخال هناك — حتى لو كان مزروعًا داخل /lib، وهي حيلة شائعة للروتكيت. تزيل المعالجة إدخالات /etc/ld.so.preload بدلاً من التعليق عليها، لأن المحمّل ليس لديه صيغة تعليق في ذلك الملف.
مثال على اكتشاف:``` [HIGH] LD_PRELOAD_INJECT Title: LD_PRELOAD set to non-standard library path Artifact: /home/alice/.bashrc Raw value: export LD_PRELOAD=/tmp/.libssl.so Remediation: available
**SUSPICIOUS_SYSTEMD_TIMER** — تُعدّ مؤقتات Systemd أكثر استمرارية وأقل وضوحًا من مهام cron بالنسبة لمعظم المستجيبين. إنّ مؤقتًا — أو وحدة `.service` عادية، وهي الأكثر شيوعًا في الاستمرارية ولا تحتاج إلى مؤقت على الإطلاق — يشير ExecStart الخاص بها إلى دليل مؤقت أو يشغّل ملفًا تنفيذيًا لا يملكه root، يُعدّ علامة على استمرارية أنشأها المهاجم. تُقرأ وحدات الخدمة مباشرةً من أدلة الوحدات، بما في ذلك `~/.config/systemd/user` لكل مستخدم. للرصد فقط — يتطلب إزالة وحدة systemd حكمًا بشريًا.
*مثال على النتيجة:*```
[HIGH] SUSPICIOUS_SYSTEMD_TIMER
Title: Systemd timer ExecStart points to suspicious path
Artifact: /etc/systemd/system/update-check.timer
Raw value: ExecStart=/tmp/.sys/update
Remediation: not available
SSH_UNAUTHORIZED_KEY — مفتاح SSH مُضاف حديثًا يمنح وصولًا عن بُعد دائمًا مستقلًا عن كلمات المرور. تلتقط نافذة الـ 7 أيام الإضافات الحديثة مع تجنّب الضجيج الناتج عن التهيئة الأولية على الأنظمة الأقدم. ملاحظة: تستخدم القاعدة وقت تعديل الملف (file mtime)، الذي يعكس آخر كتابة على ملف authorized_keys، وليس الطابع الزمني لإدراج كل مفتاح على حدة.
مثال على النتيجة:``` [MEDIUM] SSH_UNAUTHORIZED_KEY Title: SSH authorized key added in last 7 days Artifact: /home/bob/.ssh/authorized_keys Raw value: ssh-rsa AAAAB3NzaC1... attacker@evil Remediation: available
**SUDOERS_NOPASSWD** — sudo بدون كلمة مرور لحساب مستخدم بشري (UID ≥ 1000 مع صدفة تسجيل دخول) هو ناقل لتصعيد الصلاحيات يبقى بعد إزالة آليات الاستمرارية الأخرى. المنح المشروعة لـ NOPASSWD تكون دائمًا تقريبًا لحسابات الخدمات التي لا تملك صدفة تسجيل دخول. تُحل قواعد المجموعات (`%sudo ALL=(ALL) NOPASSWD:ALL`) إلى أعضائها، وتُتبع ملفات `#include`/`@includedir`. نتائج المجموعات تكون للعلم فقط: حذف قاعدة مثل `%sudo` قد يزيل كل منح sudo على النظام.
*مثال على النتيجة:*```
[MEDIUM] SUDOERS_NOPASSWD
Title: NOPASSWD sudo grant for regular user
Artifact: /etc/sudoers.d/alice
Raw value: alice ALL=(ALL) NOPASSWD: ALL
Remediation: available
PROCESS_MASQUERADE — تسمية ملف ثنائي خبيث باسم عملية نظام معروفة (sshd، python3، bash) هي تقنية أساسية لتجنب الاكتشاف في مخرجات ps. تقوم هذه القاعدة بمقارنة اسم العملية من /proc/<pid>/status مع مسار exe المُحلَّل من /proc/<pid>/exe. تشمل المواقع القياسية /usr/local/{bin,sbin}، و/usr/lib، و/usr/libexec، و/snap، لذا فإن systemd (/usr/lib/systemd/systemd) وحزم snap لا تُفعّل هذه القاعدة. للتنبيه فقط — قتل عملية يتطلب حكماً بشرياً.
مثال على اكتشاف:``` [MEDIUM] PROCESS_MASQUERADE Title: Process masquerading as system binary Artifact: /proc/1337/exe Raw value: name=sshd, exe=/tmp/.sshd Remediation: not available
**USER_UID_ZERO** — يجب أن يكون `root` فقط هو الحاصل على UID 0. أي حساب ثانٍ مرتبط بـ UID 0 (CIS Ubuntu Benchmark 6.2.x) يُعدّ بابًا خلفيًا عالي الثقة: فهو يمنح صلاحيات المستخدم الخارق الكاملة دون تغيير بيانات اعتماد root نفسه، ويظل قائمًا حتى بعد إعادة تعيين كلمة مرور root. معدل الإيجابيات الكاذبة شبه معدوم. للعلم فقط — إزالة حساب بـ UID 0 تتطلب حكمًا بشريًا.
*مثال على النتيجة:*```
[HIGH] USER_UID_ZERO
Title: Non-root account with UID 0
Artifact: /etc/passwd
Raw value: toor:x:0:0:...:/bin/bash
Remediation: not available
USER_EMPTY_PASSWORD — الحساب الذي يكون فيه حقل كلمة المرور في /etc/shadow فارغًا لا يملك كلمة مرور على الإطلاق، وتسمح له حزمة PAM الافتراضية في Ubuntu (pam_unix ... nullok) بتسجيل الدخول دون كلمة مرور. على حساب له صدفة تسجيل دخول، يُعدّ هذا بابًا مفتوحًا. للعلم فقط — اقفله باستخدام passwd -l أثناء التحقيق.
مثال على النتيجة:``` [HIGH] USER_EMPTY_PASSWORD Title: Login account with no password Artifact: /etc/shadow Raw value: eve:: Remediation: not available
**PROCESS_SUSPICIOUS_CONNECTION** — الاستمرارية ليست سوى نصف الصورة؛ فموضع قدم لا يتحدث أبدًا إلى أي شيء نادرًا ما يكون هو ما يهمك. تربط هذه القاعدة جامعي العمليات والشبكة عبر PID بحيث يصل أي عملية مُعلَّمة مرفقةً باتصالاتها الحالية. ملف تنفيذي موضوع في `/tmp` يحتفظ بمقبس صادر مُنشأ يُعد HIGH؛ بينما وصول ملف تنفيذي شرعي إلى منفذ بعيد غير قياسي يُعد MEDIUM ويستحق النظر. هذه لقطة للحالة الراهنة، وليست مراقبة مستمرة — فالمنارة التي تكون نائمة عند الفحص لن تظهر. وضع الإبلاغ فقط.
*مثال على النتيجة:*```
[HIGH] PROCESS_SUSPICIOUS_CONNECTION
Title: Process with suspicious outbound connection
Artifact: /proc/1337/exe
Raw value: 203.0.113.9:4444
Remediation: not available
SHELL_RC_MODIFICATION — تُعد ملفات تهيئة الصدفة (shell init files) ناقلًا موثوقًا للاستمرارية لأنها تُنفَّذ عند كل تسجيل دخول للمستخدم. تُظهر هذه القاعدة التعديلات الأخيرة لمراجعة بشرية. للتنبيه فقط — يتطلب محتوى ملفات تهيئة الصدفة القراءة قبل التصرف بناءً عليه.
مثال على النتيجة:``` [LOW] SHELL_RC_MODIFICATION Title: Shell init file recently modified Artifact: /root/.bashrc Raw value: mtime=2024-01-15 14:22:01 (6 hours ago) Remediation: not available
**PACKAGE_TAMPERED** — تُعدّ الملفات الثنائية وملفات التهيئة المملوكة للنظام أساس الثقة. تكشف هذه القاعدة عند تعديل الملفات المملوكة للحزم، أو حذفها، أو وجود عدم تطابق في المحتوى/الوضع/الحجم باستخدام `dpkg --verify`. يتم استبعاد التعديلات على ملفات التهيئة فقط (تغييرات التهيئة المحلية المتوقعة) من الإبلاغ لتجنب الضوضاء. وضع الإشارة فقط — قد يكون التلاعب مشروعًا (تعديلات محلية مخصصة) أو ضارًا (استبدال ملف)؛ ويتطلب القرار حكمًا بشريًا.
*مثال على اكتشاف:*```
[HIGH] PACKAGE_TAMPERED
Title: Package-owned file modified since installation
Artifact: /usr/bin/sshd
Raw value: ....5..T. (content and mtime differ)
Remediation: not available
IMMUTABLE_FLAG_SET — غالبًا ما يقوم المهاجمون بتعيين العلامة غير القابلة للتغيير (i) أو علامة الإضافة فقط (a) على الملفات لمنع تعديلها أو حذفها، حتى بواسطة root، بما في ذلك إخفاء التلاعب من التعديلات الإضافية/تدوير السجلات. يعد تعيين هذه العلامات على ملفات النظام الحساسة مثل /etc/passwd، /etc/sudoers، /etc/pam.d/*، أو ملفات سجلات auth/syslog/wtmp/btmp مؤشرًا قويًا على تقوية المهاجم. تكتشف هذه القاعدة العلامات غير القابلة للتغيير والإضافة فقط عبر lsattr مقابل تلك القائمة الثابتة من المسارات الحساسة. للعلم فقط — تتطلب تغييرات العلامات مراجعة بشرية.
مثال على النتيجة:``` [MEDIUM] IMMUTABLE_FLAG_SET Title: Sensitive file has an unexpected chattr flag Artifact: /etc/ld.so.preload Raw value: ----i--------e--- Remediation: not available
**PAM_BACKDOOR** — تُعدّ PAM (وحدات المصادقة القابلة للتوصيل) و NSS (خدمة تبديل الأسماء) الأنظمة الأساسية للمصادقة والهوية على Linux. لا تُجري هذه القاعدة كشفًا قائمًا على mtime من نوع "هل تم تعديل هذا الملف" — بل تُطابق *محتوى* الملف بنمط معيّن: (1) سطر حرفي `pam_permit.so` في أي ملف من /etc/pam.d/* (هذه الوحدة تنجح دائمًا وهي باب خلفي كلاسيكي لتجاوز المصادقة)، أو (2) وحدة NSS مُدرجة في /etc/nsswitch.conf ليست ضمن قائمة السماح المدمجة في ubuntils. **ملاحظة:** سيعطي فحص NSS نتائج إيجابية خاطئة على المضيفين المنضمّين إلى نطاق/SSSD/LDAP/Winbind الذين يستخدمون وحدة خارج قائمة السماح المدمجة — ولذلك يُقيَّم عمدًا بثقة أقل من مطابقة pam_permit.so؛ استخدم `--config` لإدراج أسماء الوحدات غير المعروفة في قائمة السماح لبيئتك. للعلم فقط — تتطلب تغييرات إعدادات المصادقة تحققًا دقيقًا.
*أمثلة على النتائج:*```
[HIGH] PAM_BACKDOOR
Title: PAM config unconditionally permits authentication
Artifact: /etc/pam.d/sshd
Raw value: auth required pam_permit.so
Remediation: not available
[HIGH] PAM_BACKDOOR
Title: Unexpected NSS module in nsswitch.conf
Artifact: /etc/nsswitch.conf
Raw value: passwd: files evilmod
Remediation: not available
KERNEL_MODULE_SUSPICIOUS — تعمل وحدات النواة في الحلقة 0 (ring 0) بوصول غير مقيّد. غالبًا ما يقوم المهاجمون بتحميل وحدات نواة مخصّصة لبرامج rootkits، أو التنصّت على الحزم، أو إخفاء العمليات. تقارن هذه القاعدة الوحدات المحمّلة حاليًا بقائمة سماح صغيرة من الوحدات المدمجة المتوقعة (الشائعة في معظم الأنظمة). درجة خطورتها LOW لأن قائمة السماح هذه ضيّقة عمدًا. ملاحظة: ستولّد المضيفات كثيفة العتاد التي تحتوي على برامج تشغيل GPU، أو بطاقات Wi-Fi، أو برامج تشغيل خاصة نتائج إيجابية خاطئة. ينبغي للمستجيبين إضافة الوحدات المتوقعة لمضيفهم عبر --config، مع إدراجها في قائمة السماح باسم الوحدة (المستخدم كـ artifact_path). وضع الإبلاغ فقط (Flag-only) — يتطلب التحقيق في وحدات النواة أدوات جنائية وخبرة بشرية.
مثال على اكتشاف:``` [LOW] KERNEL_MODULE_SUSPICIOUS Title: Loaded kernel module not in the expected set Artifact: implant_rootkit Raw value: {'name': 'implant_rootkit', 'size': '12288', 'used_by': []} Remediation: not available
**SETUID_INVENTORY** — تقوم الملفات الثنائية setuid و setgid برفع الصلاحيات تلقائيًا عند تنفيذها. ينشئ المهاجمون ملفات ثنائية setuid/setgid مخصصة لترسيخ رفع الصلاحيات، وغالبًا ما تكون خارج أدلة الملفات الثنائية القياسية للنظام (مسار تثبيت شائع مثل /opt، أو دليل /home الخاص بالمستخدم، أو /srv، أو دليل مؤقت قابل للكتابة من الجميع). يقوم هذا القاعدة بجرد الملفات الثنائية setuid/setgid عبر `find -perm -4000 -o -perm -2000` في `/usr /bin /sbin /opt /home /srv /tmp /var/tmp /dev/shm` ويضع علامة على أي منها خارج مجموعة أساسية معروفة من أدوات النظام المشروعة. وضع العلامة فقط — تتطلب الملفات الثنائية setuid/setgid غير المتوقعة تحقيقًا ولكنها قد تكون ملفات ثنائية مشروعة مثبتة بواسطة التطبيق.
*مثال على اكتشاف:*```
[LOW] SETUID_INVENTORY
Title: Unexpected setuid binary
Artifact: /tmp/.hidden/backdoor
Raw value: setuid
Remediation: not available
--json يكتب كائن JSON واحد إلى stdout. لا يُطبع أي شيء آخر.```json
{
"scan_metadata": {
"tool_version": "2.1.0",
"hostname": "web-01",
"generated_at": "2026-06-10T08:22:03.114523+00:00",
"ubuntu_version": "Ubuntu 22.04.3 LTS",
"architecture": "x86_64",
"duration_s": 2.84,
"collector_failures": 0,
"bundle_integrity": "live",
"command_collectors_skipped": [],
"collectors_degraded": {},
"rules_failed": [],
"timeline_error": null,
"suppressed_by_baseline": 1
},
"artifact_counts": {
"ProcessCollector": 142,
"NetworkCollector": 23,
"UserCollector": 4,
"CronCollector": 7,
"SystemdCollector": 12,
"SSHCollector": 3,
"SudoersCollector": 5,
"EnvironmentCollector": 18
},
"findings": [
{
"rule_id": "CRON_TMP_PATH",
"severity": "HIGH",
"title": "Cron job references writable temp directory",
"description": "A cron job was found referencing /tmp, /var/tmp, or /dev/shm. These directories are world-writable and commonly used as attacker staging grounds.",
"artifact_path": "/etc/cron.d/cleanup",
"raw_value": "0 * * * * root /tmp/.update",
"remediation_available": true,
"remediation_description": "Will remove the offending cron entry from /etc/cron.d/cleanup after creating a timestamped backup.",
"related_events": [
{
"timestamp": "2024-01-15T08:20:00+00:00",
"source": "syslog",
"description": "CRON[2841]: (root) CMD (/tmp/.update)"
}
],
"confidence": 75,
"confidence_band": "HIGH",
"signals": [
{"name": "timeline_corroboration", "weight": 25, "detail": "1 nearby timeline event(s)"}
]
},
{
"rule_id": "PROCESS_MASQUERADE",
"severity": "MEDIUM",
"title": "Process masquerading as system binary",
"description": "Process 'sshd' (pid=1337) has exe path outside standard binary directories: /tmp/.sshd",
"artifact_path": "/proc/1337/exe",
"raw_value": "/tmp/.sshd",
"remediation_available": false,
"guided_remediation": "Confirm pid 1337 is malicious (ls -l /proc/1337/exe, cat /proc/1337/cmdline), then terminate it: kill -9 1337.",
"confidence": 50,
"confidence_band": "MEDIUM",
"signals": []
}
],
"timeline": [
{
"timestamp": "2024-01-15T08:22:01+00:00",
"source": "syslog",
"description": "sshd: Accepted publickey for alice from 10.0.0.42 port 52341"
}
],
"report_sha256": "a3f1c9…(64 hex chars)"
}
يظهر `remediation_results` كمفتاح إضافي في المستوى الأعلى فقط عند تمرير `--remediate`. يكون `report_sha256` موجودًا دائمًا ويُحسب على بقية المستند. تكون قيمة `scan_metadata.bundle_integrity` هي `"live"` بالنسبة إلى `scan` و`analyze --root`، و`"ok"` بالنسبة إلى حزمة تم التحقق منها وتمريرها إلى `analyze`، و`"mismatch"` إذا لم يطابق محتوى الحزمة بيانها الوصفي — راجع [سلامة الحزمة في مخرجات JSON](#bundle-integrity-in-json-output). يسمّي `scan_metadata.command_collectors_skipped` أي جامعات تعتمد على الأوامر (`NetworkCollector`، `SystemdCollector`، `PackageCollector`، `KernelCollector`) تم تخطيها في تشغيل `--root` — ويكون فارغًا دائمًا بالنسبة إلى `scan` و`analyze BUNDLE`. يمثّل `scan_metadata.suppressed_by_baseline` عدد النتائج التي أزالها ملف `--baseline` من هذا التقرير — راجع [Baselining المعروف بأنه سليم](#known-good-baselining---baseline). يربط `scan_metadata.collectors_degraded` اسم الجامع بالأسباب التي جعلت بياناته غير مكتملة (أمر فشل أو انتهت مهلته، ملف غير قابل للقراءة، سطر مشوّه تم تخطيه)، ويسرد `rules_failed` أي قاعدة كشف انهارت، ويُضبط `timeline_error` إذا تعذّر بناء الخط الزمني. تكون الثلاثة جميعها فارغة في تشغيل سليم. تحقق منها قبل قراءة قائمة نتائج فارغة على أنها "نظيفة".
يظهر `related_events` و`guided_remediation` على نتيجة فقط عندما يكون لهما محتوى. يحتفظ `related_events` بما يصل إلى خمسة أحداث من الخط الزمني مطابقة للنتيجة حسب مسار الأثر وكلمات القاعدة المفتاحية، الأحدث أولًا — وهو أداة مساعدة على الإبراز، وليس ادعاءً سببيًا. أما `guided_remediation` فهو تسلسل أوامر مُراجَع لتشغيله يدويًا؛ ولا ينفّذه ubuntils أبدًا.
### تسجيل الثقة
تحمل كل نتيجة درجة `confidence` (من 0 إلى 100، الافتراضي 50) و`confidence_band` (`HIGH` ≥ 75، `MEDIUM` ≥ 40، `LOW` أقل من ذلك)، إضافة إلى قائمة `signals` تُظهر بالضبط كيف تم الوصول إلى تلك الدرجة — كل مدخل هو `{"name", "weight", "detail"}`، لذا تكون الدرجة قابلة للتفسير دائمًا، وليست صندوقًا أسود أبدًا. الإشارات تُضاف فوق ثقة أساسية قدرها 50 وتُطبّقها القاعدة أو مرحلة خط المعالجة التي أنتجتها:
- تطبّق قواعد الكشف إشاراتها الخاصة وقت اكتشاف النتيجة — على سبيل المثال يضيف `SSH_UNAUTHORIZED_KEY` و`SHELL_RC_MODIFICATION` الإشارة `content_match` (+30) عندما يطابق محتوى الأثر نمطًا معروف الخطورة (خيار مفتاح SSH خطير؛ سطر curl/wget-to-shell أو base64-decode في ملف RC للصدفة)، والإشارة `ctime_corroborates_mtime` (+20) عندما يكون ctime الخاص بالملف أيضًا داخل نافذة الكشف (وهو أصعب في التزوير من mtime وحده)، أو الإشارة `mtime_only` (−20) عندما تكون الحداثة هي الإشارة *الوحيدة* ولا يؤكدها ctime — وهو مؤشر على أن mtime ربما تم تأريخه بتاريخ سابق.
- يطبّق خط المعالجة الإشارة `timeline_corroboration` (+25) بعد الربط بين النتيجة والخط الزمني، عندما تكون للنتيجة حدث أو أكثر من `related_events`.
لا يتم تجاهل نتيجة النطاق `LOW` أو إخفاؤها — فهي تظهر في قائمة النتائج ومخرجات JSON تمامًا مثل أي نتيجة أخرى — لكن النطاق يخبرك بمقدار الوزن الذي ينبغي أن توليه لها قبل التحقيق أكثر. وهذا يحل محل الاستدلال القديم القائم على mtime وحده بالنسبة إلى `SSH_UNAUTHORIZED_KEY`/`SHELL_RC_MODIFICATION`، حيث كان ملف قديم لكن تم لمسه بشكل مشروع (مثل أداة إدارة إعدادات تعيد كتابة `.bashrc` في كل تشغيل) يبدو مطابقًا لباب خلفي جديد حقيقي.
**قيد معروف:** الإشارات النشطة اليوم هي إشارات نمط المحتوى وctime فقط. أما الإشارات القائمة على الملكية/البصمة — بصمة مفتاح SSH غير معروفة، أو خيار التقييد `from=` لمفتاح، أو عدم تطابق المالك/الوضع لملف RC (إشارة `ownership_anomaly`) — فلم تُنفَّذ بعد. وهذه فجوة تغطية مؤجلة، متتبَّعة لإصدار مستقبلي، وليست شيئًا تراعيه درجة الثقة الحالية.
---
## المعالجة
خمس من قواعد الكشف الست عشرة لديها معالجة آلية: `CRON_ROOT_EXEC`، `CRON_TMP_PATH`، `LD_PRELOAD_INJECT`، `SSH_UNAUTHORIZED_KEY`، و`SUDOERS_NOPASSWD`. أما البقية فهي للتنبيه فقط ولن تتم معالجتها آليًا أبدًا، لأن التصرف بشأنها بأمان يتطلب أن ينظر إنسان أولًا.
### المعالجة الموجَّهة
تحمل `SUSPICIOUS_SYSTEMD_TIMER` و`PROCESS_MASQUERADE` و`SHELL_RC_MODIFICATION` سلسلة `guided_remediation`: الأوامر الدقيقة التي يجب تشغيلها بمجرد تأكيد النتيجة — `systemctl disable --now <unit>`، أو `kill -9 <pid>`، أو مراجعة ملف RC والرجوع عنه. تظهر في لوحة تفاصيل TUI وفي JSON. ولا يشغّلها ubuntils نيابة عنك أبدًا؛ فهذه القواعد تبقى خارج عملية `--remediate --confirm` بحكم التصميم.
### في TUI
اختر أي نتيجة لديها معالجة في تبويب Findings، ثم اضغط `R`. تعرض نافذة تأكيد منبثقة معاينة للإجراء المخطط. اضغط `Y` لتطبيقه — يعمل المُعالِج في خيط خلفي حتى يبقى TUI سريع الاستجابة. يتحدّث صف النتيجة إلى `[fixed]` عند الانتهاء، مع عرض مسار النسخة الاحتياطية وأمر التراجع الدقيق مباشرةً.
### من CLI
`--remediate` بدون `--confirm` هو تشغيل تجريبي آمن: تُنشأ النسخ الاحتياطية ويعمل التحقق، لكن لا تُطبَّق أي تغييرات. مرّر كلا العلَمين لإجراء تغييرات فعلية. يعمل خط المعالجة قبل تشغيل TUI في هذا الوضع، ويسرد تبويب Summary كل نتيجة معالجة مع مسار النسخة الاحتياطية وأمر التراجع الخاص بها.
لا يعمل `--remediate --confirm` إلا على النتائج التي لديها درجة ثقة لا تقل عن 40 (نطاق MEDIUM) — فالنتيجة `SSH_UNAUTHORIZED_KEY` منخفضة الثقة والقائمة على mtime وحده تُبلَّغ على أنها `SKIPPED` بدلًا من حذف مفتاحها. اضبط العتبة باستخدام `--min-confidence N`.```bash
sudo ubuntils scan --remediate # dry run
sudo ubuntils scan --remediate --confirm # apply changes, then open TUI
sudo ubuntils scan --remediate --confirm --min-confidence 75 # only HIGH-confidence findings
تتبع كل عملية معالجة النمط نفسه بغض النظر عن كيفية تشغيلها:
/var/backups/ubuntils/YYYYMMDD_HHMMSS/ بوضع 0700/etc/ld.so.preload (لا يحتوي المحمّل على صيغة تعليق هناك، لذا فإن الإدخال المعلّق سيظل يُحمَّل). بالنسبة لـ sudoers، يتم فحص المحتوى المعدّل باستخدام visudo -cf على نسخة مؤقتة قبل لمس الملف الحقيقي/etc/sudoers مبتورًاإذا فشلت أي خطوة، تتوقف المعالجة فورًا، ويُترك النظام دون تغيير، ويُبلَّغ عن الخطأ الكامل مع مسار النسخة الاحتياطية وأمر التراجع. وصول sudo محمي بطريقتين: قواعد %group NOPASSWD (مثل %sudo) هي للإشارة فقط ولا تُزال تلقائيًا أبدًا، ويرفض معالج sudoers إزالة القاعدة الأخيرة من ملف sudoers الرئيسي.
صُمم ubuntils لفرز نقطي على مضيف واحد — تشغّله عندما تشك بالفعل في وجود خطب ما، ولا يتصل بالخارج أبدًا ولا يواصل المراقبة بعد انتهاء الفحص. هذا أمر مقصود، لكنه يعني أيضًا أن نتيجة من ubuntils تعيش فقط في ذلك التقرير الواحد ما لم يحملها شيء إلى الأمام. معظم الفرق التي تشغّل Ubuntu بأي حجم لديها بالفعل SIEM يقوم بالجانب المستمر من الكشف، لذا بدلًا من بناء ubuntils كوكيل مراقبة طويل الأمد خاص به، فإنه يسلّم نتائجه إلى الوكيل الذي تشغّله على الأرجح بالفعل: Wazuh.
إذا كان وكيل Wazuh موجودًا على المضيف (يوجد /var/ossec/bin/wazuh-agentd أو /var/ossec/etc/ossec.conf)، فإن ubuntils scan (ما لم يُشغَّل مع --no-wazuh) يضيف كل نتيجة كسطر JSON واحد إلى /var/log/ubuntils/wazuh-alerts.json ليلتقطه الوكيل — هذا مجرد مُمرِّر، وليس وحدة Wazuh: لا اتصال شبكي، لا مفتاح API، لا شيء سوى نفس كتابات العناصر المحلية التي يقوم بها ubuntils بالفعل — رغم أن الوكيل سيشحن تلك الأسطر بالطبع خارج المضيف إلى مديره؛ وهذا هو المقصود. يُكتشف تلقائيًا دون الحاجة إلى علم (استخدم --no-wazuh لاستثناء تشغيل ما)، لذا فإن ubuntils scan المجدول أو النصي على أسطول من المضيفين المسجلين في الوكيل يبدأ بتغذية SIEM فورًا دون أي توصيل إضافي. لا يحدث هذا أبدًا أثناء ubuntils analyze دون اتصال (حزمة أو --root)، لأن تلك النتائج تصف مضيفًا مختلفًا عن المضيف الذي يشغّل وكيل Wazuh المحلي — فتوجيه نتائج حزمة إلى وكيل المحلل نفسه سينسبها خطأً إلى الجهاز الخاطئ.
الهدف هو دمج ubuntils في خط تنبيه/تصعيد قائم بدلًا من مطالبة المستجيب برعاية أداة ثانية: بمجرد تحميل القواعد النموذجية أدناه، تظهر نتيجة ubuntils بخطورة HIGH (حساب UID-0 جديد، روتكيت LD_PRELOAD، باب خلفي PAM) كتنبيه Wazuh عادي، وترث أي توجيه إشعارات مُهيَّأ بالفعل لدى المدير، وتجلس إلى جانب كل إشارة أخرى في نفس الخط الزمني بدلًا من ملف JSON مستقل يجب على أحدهم تذكّر التحقق منه.
لجعل Wazuh يحلل هذه النتائج وينبّه عليها، انسخ القواعد النموذجية من examples/wazuh/ إلى مدير Wazuh لديك، وأضف كتلة <localfile> من examples/wazuh/ossec_localfile_snippet.xml إلى /var/ossec/etc/ossec.conf الخاص بالوكيل. لا حاجة لتثبيت مفكك ترميز مخصص: يُهيَّأ localfile بـ log_format json، لذا يفكك مفكك ترميز JSON المدمج في Wazuh كل سطر ويحوّل كل مفتاح JSON من المستوى الأعلى k إلى data.k، وهو ما يطابقه local_rules.xml مباشرة.
examples/wazuh/local_rules.xml → /var/ossec/etc/rules/ الخاص بالمدير<localfile> من examples/wazuh/ossec_localfile_snippet.xml → /var/ossec/etc/ossec.conf الخاص بالوكيلsystemctl restart wazuh-manager (المدير)، systemctl restart wazuh-agent (مضيف الوكيل)هذه قوالب نموذجية فقط، تُقدَّم كنقطة انطلاق — لم تُختبر مقابل مدير Wazuh حي ويجب التحقق منها في بيئة غير إنتاجية قبل الاعتماد عليها.
مخطط JSON لكل سطر:
يتطلب PackageCollector ثلاث أدوات Ubuntu قياسية على المضيف الحي (dpkg، lsattr، find — جميعها موجودة في تثبيتات Ubuntu الأصلية). إذا كان أي أمر غير متاح، ينتج PackageCollector بيانات فارغة لذلك الجزء بدلًا من الانهيار. يعيد التحليل دون اتصال (analyze BUNDLE) تشغيل مخرجات الأوامر الملتقطة من وقت collect، لذا لا يُشترط توفر الأوامر على مضيف المحلل.
يمرر فحص find لـ setuid/setgid الخيار -xdev ليبقى محدودًا — فهو لا ينزل إلى أنظمة ملفات مركّبة بشكل منفصل (تركيب مميز تحت /opt، أو /home المركّب عبر NFS، إلخ). هذه مقايضة متعمدة بين وقت التشغيل والتغطية: بدون -xdev، قد يتعلّق الفحص أثناء مسح تركيبات الشبكة أو أنظمة الملفات الافتراضية. إذا كان بيئتك تركّب هذه المسارات على أنظمة ملفات منفصلة، فاعلم أنها لن تُفحص.
يستخدم dpkg --verify وفحص find لـ setuid/setgid مهلًا سخية غير افتراضية (10 دقائق و5 دقائق على التوالي، انظر ubuntils/collectors/packages.py) لأن كليهما يمكن أن يعمل بشكل مشروع لفترة تتجاوز بكثير الافتراضي المكتبي البالغ 30 ثانية على مضيف حقيقي بقاعدة حزم أو شجرة نظام ملفات كبيرة؛ ويستخدم ubuntils collect نفس المهل عند التقاط هذه الأوامر في حزمة.
| مدعوم | |
|---|---|
| Ubuntu | 20.04، 22.04، 24.04 |
| المعمارية | amd64، arm64 |
| Python | 3.9+ |
| الصلاحيات | مطلوب root للوصول الكامل إلى العناصر |
التشغيل بدون root ينتج فحصًا جزئيًا مع تحذيرات. سيتم تخطي المسارات الحرجة مثل /etc/shadow، وأدلة crontab المحمية، وبعض إدخالات /proc.
v1.0.0
v1.1.0
--config)--output FILE لكتابة التقارير مباشرة--sincereport_sha256، hostname، timestamp)USER_UID_ZEROv1.5.0
--rules)PROCESS_SUSPICIOUS_CONNECTION — ربط العملية↔الشبكة عبر PIDrelated_events)تم إسقاط عمليات بحث تجزئة VirusTotal وتصدير MISP IOC من هذا الإصدار. يجيب VirusTotal فقط عن التجزئات المعروفة — وهي الحالة التي يغطيها rkhunter بالفعل، وعكس الفجوة في التقنيات الجديدة التي يستهدفها ubuntils — وكانت كلتا الميزتين ستضعان اتصالًا شبكيًا داخل أداة تقوم قيمتها على عدم إجراء أي اتصال. لا يزال ubuntils نفسه لا يجري أي اتصالات شبكية (انظر تكامل Wazuh للطريقة الوحيدة القابلة للاستثناء التي يمكن بها للنتائج مغادرة المضيف، عبر وكيل محلي).
v2.0.0 — فصل collect/analyze دون اتصال
ubuntils collect — يحصل على حزمة مقاومة للتلاعب (manifest.json + ملفات/أوامر مجزّأة) من مضيف حي، دون كشفubuntils analyze (BUNDLE | --root PATH) — يشغّل نفس خط أنابيب الكشف/الخط الزمني مثل scan مقابل حزمة أو صورة مركّبة، دون الحاجة إلى rootbundle_integrity (live/ok/mismatch) تظهر في scan_metadataPROCESS_MASQUERADE، PROCESS_SUSPICIOUS_CONNECTION، وتغطية مخفّضة لمسارات cron/sudoers/SSH العامة و لمؤقت systemd)v2.1.0 — توجيه SIEM
ubuntils scan الحية تُوجَّه إلى وكيل Wazuh محلي كـ JSONL، مع اكتشاف تلقائي (لا حاجة إلى علم)<localfile> في ossec.conf (examples/wazuh/)scan الحي فقط — لا يُطلق أبدًا أثناء analyze دون اتصال، لأن حزمة أو صورة تصف مضيفًا مختلفًا عن المضيف الذي يشغّل الوكيل--no-wazuh لاستثناء فحص من التوجيهv2.1.0 — تقوية (تدقيق كامل لقاعدة الكود)
PATH الخاص بالمتصل، وتُحل الأوامر على مسار آمن ثابت؛ تعديلات sudoers تُفحص بـ visudo قبل لمس الملف؛ كتابات معالجة ذرية؛ إخراج تقرير/حزمة آمن من الروابط الرمزية؛ حذف الحزم المستخرجة بعد analyze/etc/ld.so.preload، إدخالات cron @reboot/@daily وسكربتات /etc/cron.{hourly,daily,weekly,monthly}، وحدات systemd .service والثنائيات ExecStart غير المملوكة لـ root، قواعد sudoers %group و #include/@includedir، كل عنصر في قائمة LD_PRELOADv3.0.0 / v4.0.0 (استكشافية)
أكثر المساهمات فائدة الآن هي قواعد الكشف الجديدة (تُضاف كدوال مستقلة في detectors/rules.py مع اختبار مطابق)، ومجمّعات إضافية لأنواع العناصر غير المغطاة بعد، ووحدات معالجة لـ SUSPICIOUS_SYSTEMD_TIMER و SHELL_RC_MODIFICATION (كلتاهما حاليًا للإشارة فقط بحكم التصميم، لكن قد توجد مسارات معالجة تلقائية آمنة)، وحالات اختبار للحالات الحدية على تهيئات Ubuntu محددة، وتحسينات التوثيق.
افتح مشكلة قبل بدء مساهمة كبيرة لتجنب العمل المكرر.
MIT
بُني بواسطة Asmit — بكالوريوس تقنية في علوم الحاسوب، جامعة PES، بنغالورو. جاءت الأداة من الإحباط بسبب المدة التي يستغرقها الفرز اليدوي لـ Ubuntu مقارنة بما يمكن لسكربت محدد النطاق أتمتته.
/var/log/syslog/var/log/messages/var/log/audit/audit.logjournalctl| المفتاح | علامة التبويب | المحتويات |
|---|
1 | الملخص | إحصاءات الفحص + أهم النتائج في لمحة |
2 | النتائج | قائمة النتائج الكاملة مع التفاصيل المضمّنة والمعالجة |
3 | الجدول الزمني | أحداث السجل المترابطة زمنيًا |
4 | الإحصاءات | إصدار Ubuntu، والبنية، والمدة، وأعداد المجمّعات |
| معرّف القاعدة | الخطورة | قابل للمعالجة | ما الذي يتحقق منه |
|---|
| CRON_ROOT_EXEC | عالية | نعم | مهام cron للمستخدمين غير الجذر التي تشغّل أوامر في مسارات مملوكة للجذر أو تُضمّن sudo |
| CRON_TMP_PATH | عالية | نعم* | أي مهمة cron (بما في ذلك إدخالات @reboot/@daily والسكربتات في /etc/cron.{hourly,daily,weekly,monthly}) تشير إلى /tmp أو /var/tmp أو /dev/shm. *أسطر السكربتات للعلم فقط |
| LD_PRELOAD_INJECT | عالية | نعم | أي إدخال في /etc/ld.so.preload (فارغ في Ubuntu الأصلي)، أو LD_PRELOAD في أي ملف تهيئة shell مع أي مكتبة مُدرجة خارج /lib و/usr/lib و/lib64 و/usr/lib64 |
| SUSPICIOUS_SYSTEMD_TIMER | عالية | لا | مؤقتات systemd ووحدات الخدمة التي يشير ExecStart الخاص بها إلى دليل قابل للكتابة من الجميع أو يشغّل ملفًا تنفيذيًا غير مملوك للجذر |
| SSH_UNAUTHORIZED_KEY | متوسطة | نعم | ملفات authorized_keys التي عُدّلت خلال آخر 7 أيام |
| USER_UID_ZERO | عالية | لا | أي حساب غير root بمعرّف UID صفر (مستخدم خارق ثانٍ مخفي) |
| USER_EMPTY_PASSWORD | عالية | لا | حساب بصدفة تسجيل دخول حقل كلمة المرور الخاص به في /etc/shadow فارغ (إعداد PAM الافتراضي nullok في Ubuntu يسمح له بتسجيل الدخول بدون كلمة مرور) |
| SUDOERS_NOPASSWD | متوسطة | نعم* | منح sudoers من نوع NOPASSWD لمستخدمين بمعرّف UID ≥ 1000 ولديهم صدفة تسجيل دخول، مباشرة أو عبر قاعدة %group؛ يتم تتبع الملفات المُضمّنة. *قواعد المجموعات للعلم فقط (إزالة %sudo قد تزيل كل وصول sudo) |
| PROCESS_MASQUERADE | متوسطة | لا | العمليات التي يطابق اسمها ملفًا تنفيذيًا نظاميًا معروفًا لكن ملفها التنفيذي خارج أدلة النظام القياسية (/usr/bin، /usr/sbin، /bin، /sbin، /usr/local/{bin,sbin}، /usr/lib، /usr/libexec، /lib، /snap) |
| PROCESS_SUSPICIOUS_CONNECTION | عالية / متوسطة | لا | العمليات التي تحتفظ باتصال صادر وملفها التنفيذي في دليل مؤقت قابل للكتابة من الجميع أو محذوف من القرص (عالية)، أو خارج أدلة النظام القياسية أو تتحدث إلى منفذ بعيد غير قياسي (متوسطة) |
| SHELL_RC_MODIFICATION | منخفضة | لا | ملفات تهيئة shell (bashrc، profile، zshrc، إلخ) التي عُدّلت خلال آخر 48 ساعة لأي مستخدم لديه صدفة تسجيل دخول |
| PACKAGE_TAMPERED | عالية | لا | ملفات الحزم المملوكة للنظام التي عُدّلت أو فُقدت أو التي لا يتطابق محتواها/وضعها/حجمها مع بيان الحزمة (عبر dpkg --verify) |
| IMMUTABLE_FLAG_SET | متوسطة | لا | أعلام غير قابلة للتغيير (i) أو للإلحاق فقط (a) مضبوطة على ملفات حساسة مثل /etc/passwd أو /etc/sudoers أو /etc/pam.d/* (تُكتشف عبر lsattr) |
| PAM_BACKDOOR | عالية | لا | سطر حرفي pam_permit.so في أي ملف من /etc/pam.d/*، أو وحدة NSS في /etc/nsswitch.conf خارج قائمة مسموح بها (files/sss/ldap/winbind/...) |
| KERNEL_MODULE_SUSPICIOUS | منخفضة | لا | وحدات kernel المحمّلة خارج قائمة مسموح بها من الوحدات المدمجة الشائعة — ملاحظة: المضيفات كثيفة العتاد (وحدات GPU، بطاقات Wi-Fi، التعريفات الاحتكارية) سترى نتائج إيجابية خاطئة؛ أضف الوحدات المتوقعة عبر --config |
| SETUID_INVENTORY | منخفضة | لا | ملفات تنفيذية setuid أو setgid غير متوقعة خارج مجموعة أساسية معروفة (يتم فحص البتّين والإبلاغ عنهما بشكل منفصل) |
| الحقل | النوع | الوصف |
|---|
timestamp | string (ISO 8601) | وقت توجيه النتيجة |
hostname | string | المضيف المفحوص |
rule_id | string | يطابق معرّف قاعدة الكشف في ubuntils (انظر جدول قواعد الكشف أعلاه) |
severity | string | HIGH | MEDIUM | LOW |
title | string | عنوان قصير مقروء للبشر |
description | string | وصف النتيجة الكامل |
artifact_path | string | مسار الملف/المورد حيث وُجدت المشكلة |
raw_value | string | السطر/القيمة الخام التي أطلقت القاعدة |
remediation_available | bool | ما إذا كان لدى ubuntils معالج لهذه القاعدة |
related_events | array (اختياري) | أحداث الخط الزمني المترابطة، إن وُجدت |
| المجمّع | العناصر المجمّعة |
|---|
| ProcessCollector | العمليات قيد التشغيل من /proc ومخرجات ps |
| NetworkCollector | الاتصالات المفتوحة والمستمعون من ss/netstat |
| UserCollector | /etc/passwd، /etc/shadow، /etc/group |
| CronCollector | أدلة /etc/cron* و /var/spool/cron/crontabs/* |
| SystemdCollector | مخرجات systemctl list-timers و list-units |
| SSHCollector | ~/.ssh/authorized_keys لجميع المستخدمين |
| SudoersCollector | /etc/sudoers وجميع الملفات تحت /etc/sudoers.d/ |
| EnvironmentCollector | /etc/environment، /etc/profile.d/*، ملفات تهيئة صدفة المستخدم |
| PackageCollector | سلامة حزم النظام عبر dpkg --verify، وسمات علم الثبات عبر lsattr، والثنائيات setuid/setgid عبر find |
| PamCollector | ملفات /etc/pam.d/* و /etc/nsswitch.conf |
| KernelCollector | وحدات النواة المحمّلة عبر lsmod |
ExecStartconfidence/confidence_band/signals)، كبت --baseline، استبدال الاستدلالات المعتمدة على mtime فقط في SSH_UNAUTHORIZED_KEY/SHELL_RC_MODIFICATION بإشارات ctime + المحتوى، وخط زمني حقيقي دون اتصال لكل من analyze BUNDLE و analyze --rootPACKAGE_TAMPERED، IMMUTABLE_FLAG_SET، PAM_BACKDOOR، KERNEL_MODULE_SUSPICIOUS، SETUID_INVENTORY (عبر PackageCollector، PamCollector، KernelCollector؛ جميعها للإشارة فقط بحكم التصميم)USER_EMPTY_PASSWORD الجديدة (حساب دخول بلا كلمة مرور)/usr/lib كقياسية، تخفيض KERNEL_MODULE_SUSPICIOUS إلى LOW، نتيجة NSS واحدة لكل وحدةscan_metadata و TUI؛ فشل الخط الزمني لم يعد يتجاهل النتائج؛ الحزم المتلاعب بها تحذّر وتخرج بالرمز 3؛ معالجة سنة/منطقة زمنية syslog بشكل صحيح--min-confidence (افتراضي 40)، النتائج تظهر في TUI بعد scan --remediate