ubuntils

लाइव Ubuntu सिस्टम के लिए फ़ॉरेंसिक ट्राइएज — स्वचालित आर्टिफ़ैक्ट संग्रह, पर्सिस्टेंस डिटेक्शन, और 5 सेकंड से कम समय में निर्देशित रेमेडिएशन।

समस्या

जब आपको संदेह हो कि कोई Linux सिस्टम कंप्रोमाइज़ हो गया है, तो पहले 30-40 मिनट आमतौर पर वही दस कमांड क्रम से चलाने में बीत जाते हैं: चल रही प्रोसेस जाँचें, अजीब cron जॉब्स खोजें, LD_PRELOAD के लिए grep करें, authorized_keys में नई एंट्रीज़ स्कैन करें, sudoers का ऑडिट करें। हर चरण मैन्युअल है, बार-बार संदर्भ बदलना पड़ता है, और दबाव में त्रुटि-प्रवण होता है। एक भी स्रोत छूट जाए — मान लीजिए, केवल /etc/sudoers के बजाय /etc/sudoers.d/, या /etc/cron.d/ के अलावा यूज़र crontabs — तो आपके पास अधूरी तस्वीर होती है।

मौजूदा विकल्प इसे साफ़-सुथरे ढंग से हल नहीं करते। lynis एक हार्डनिंग ऑडिटर है, ट्राइएज टूल नहीं — यह साफ़ सिस्टम पर कॉन्फ़िगरेशन कमज़ोरियाँ रिपोर्ट करता है और संक्रमित सिस्टम पर शोर पैदा करता है। chkrootkit और rkhunter ज्ञात rootkit सिग्नेचर जाँचते हैं लेकिन नई पर्सिस्टेंस तकनीकों के प्रति अंधे हैं, जैसे दुरुपयोग किए गए systemd timers या वैध दिखने वाली cron एंट्रीज़। सामान्य SIEM क्वेरीज़ के लिए लॉग इन्फ्रास्ट्रक्चर चाहिए जो उस सिस्टम पर मौजूद नहीं हो सकता जिसे आप देख रहे हैं। और Volatility जैसी फ़ॉरेंसिक सूट मेमोरी इमेज को लक्षित करती हैं, चल रहे होस्ट पर लाइव शेल को नहीं।

कमी एक ऐसे टूल की है जो अभी लाइव सिस्टम पर चले, सबसे आम पर्सिस्टेंस वेक्टर कवर करे, लॉग स्रोतों में गतिविधि को एक टाइमलाइन में सहसंबंधित करे, और आपको ठीक-ठीक बताए कि क्या देखना है — बिना किसी बाहरी एजेंट, डेटाबेस, या इंटरनेट कनेक्शन की आवश्यकता के।

ubuntils क्या करता है

ubuntils चार क्रमिक चरणों में चलता है:

1. संग्रह — ग्यारह कलेक्टर /proc, cron टेबल, systemd यूनिट, SSH कुंजियाँ, sudoers फ़ाइलें, environment परिभाषाएँ, पैकेज इंटीग्रिटी (dpkg --verify), PAM/NSS कॉन्फ़िग, और लोडेड kernel मॉड्यूल से समवर्ती रूप से फ़ॉरेंसिक आर्टिफ़ैक्ट इकट्ठा करते हैं। एक सामान्य सिस्टम पर लगभग 2.5 सेकंड लेता है।
2. डिटेक्शन — एक डिटेक्शन इंजन सभी सोलह अंतर्निहित नियम — साथ ही --rules के साथ लोड किए गए कोई भी कस्टम नियम — एकत्रित आर्टिफ़ैक्ट पर चलाता है, जिससे लगभग एक सेकंड में एक रैंक्ड, कॉन्फ़िडेंस-स्कोर वाली फ़ाइंडिंग्स सूची तैयार होती है।
3. टाइमलाइन — एक टाइमलाइन बिल्डर syslog, journald, और auditd को समानांतर में पढ़ता है और घटनाओं को कालानुक्रमिक रूप से सहसंबंधित करता है, जिसमें लगभग 0.3 सेकंड जुड़ते हैं। फिर प्रत्येक फ़ाइंडिंग को टाइमलाइन के विरुद्ध स्वतः सहसंबंधित किया जाता है, ताकि वह अपने से संबंधित आस-पास की घटनाएँ साथ रखे।
4. आउटपुट — परिणाम या तो एक इंटरैक्टिव चार-टैब TUI (डिफ़ॉल्ट) में दिखाई देते हैं या stdout पर संरचित JSON के रूप में (--json)।

ubuntils स्वयं कोई नेटवर्क कॉल नहीं करता, और हर सुविधा — कस्टम नियम और सहसंबंध सहित — स्थानीय रूप से एकत्रित आर्टिफ़ैक्ट पर चलती है। फ़ाइंडिंग्स के होस्ट से बाहर जाने का एकमात्र तरीका Wazuh इंटीग्रेशन है: यदि कोई Wazuh एजेंट इंस्टॉल है, तो एक लाइव scan अपनी फ़ाइंडिंग्स को एक स्थानीय फ़ाइल में लिखता है जिसे एजेंट फिर अपने मैनेजर तक भेजता है। किसी रन के लिए इसे बंद करने के लिए --no-wazuh पास करें।

ubuntils scan नीचे दी गई किसी भी चीज़ से अपरिवर्तित है — यह अभी भी 100% लाइव, सिंगल-होस्ट है, और हर मौजूदा फ़्लैग समान रूप से काम करता है। दो अतिरिक्त कमांड, collect और analyze, उसी डिटेक्शन/टाइमलाइन पाइपलाइन को एक ऑफ़लाइन-अनुकूल acquire-then-analyze वर्कफ़्लो में विभाजित करते हैं, उन मामलों के लिए जहाँ आप जाँचाधीन होस्ट पर सीधे डिटेक्शन नहीं चला सकते (या नहीं चलाना चाहते) — नीचे ऑफ़लाइन विश्लेषण: collect और analyze देखें, जिसमें इसकी डिटेक्शन-कवरेज चेतावनियाँ भी शामिल हैं।

इंस्टॉलेशन

Ubuntu 22.04+ और PEP 668 वाला कोई भी सिस्टम (अनुशंसित):

Ubuntu 22.04+ सिस्टम-व्यापी pip install को ब्लॉक करता है। pipx का उपयोग करें — यह environment को पारदर्शी रूप से संभालता है ताकि आपको इसके बारे में कभी सोचना ही न पड़े:```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 को गैर-रूट उपयोगकर्ता के रूप में चलाते हैं, तो यह स्वचालित रूप से उसी Python इंटरप्रेटर (पूर्ण पथ द्वारा) का उपयोग करके sudo के साथ स्वयं को पुनः आमंत्रित करेगा, ताकि आपके 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 remediation preview के साथ पहचान (dry run — कोई बदलाव लागू नहीं किए गए):```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

See ऑफ़लाइन विश्लेषण: एकत्र करें और विश्लेषण करें बंडल प्रारूप के लिए और — महत्वपूर्ण रूप से — लाइव 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-प्रबंधित होस्ट अपेक्षित शोर उत्पन्न करता है — डिप्लॉय कुंजियाँ, प्रोविज़निंग crontabs, बेक-इन शेल init। प्रतिक्रियाकर्ताओं को इसे मानसिक रूप से फ़िल्टर करना सिखाने के बजाय, इसे 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

I'm sorry, but I don't see any content to translate in your message. You mentioned "INPUT:" but no actual text followed it.

Please provide the Markdown content for chunk 25 of 90, and I'll translate it from English to Hindi according to the rules you've specified.```bash sudo ubuntils scan --json --config allowlist.yaml

दमन हमेशा स्पष्ट होता है — नियम आईडी और/या सटीक आर्टिफैक्ट पथ द्वारा। कोई सर्वव्यापी "सब कुछ अनदेखा करें" स्विच नहीं है। एक नमूना [`examples/allowlist.yaml`](https://github.com/asmitdesai/ubuntils/blob/main/examples/allowlist.yaml) पर मौजूद है।

### ज्ञात-अच्छा बेसलाइनिंग (`--baseline`)

`--config` किसी नियम या पथ को *हर जगह, इस कोडबेस के विरुद्ध ubuntils चलाने वाले किसी भी व्यक्ति के लिए* दबा देता है। `--baseline` अधिक संकीर्ण और पर्यावरण-विशिष्ट है: यह कहता है "इस पर्यावरण में, यह सटीक आर्टिफैक्ट — यह SSH कुंजी, यह RC फ़ाइल — ज्ञात-अच्छा है," बिना उस नियम या पथ को उन सभी अन्य होस्टों के लिए म्यूट किए जिन्हें आप उसी टूल से स्कैन करते हैं। इसे `--config` से अलग फ़ाइल के रूप में रखा गया है उसी कारण से जिस कारण `--rules` अलग है: दमन और नियम-व्यापी अनुमतिसूची अलग-अलग मामले हैं जिन्हें एक ही फ़ाइल में नहीं रहना चाहिए।```yaml
# baseline.yaml
baseline:
  - rule_id: SSH_UNAUTHORIZED_KEY
    fingerprint: ci@ci-runner          # substring match against the finding's raw_value
  - rule_id: SHELL_RC_MODIFICATION
    fingerprint: /home/deploy/.bashrc  # exact match against the finding's artifact_path

| -l | --list | List all available modules | | -m | --module | Specify module to use | | -o | --output | Output file path | | -v | --verbose | Enable verbose output | | -h | --help | Show help message |

उदाहरण

# List all modules
python3 kitploit.py -l

# Run a specific module
python3 kitploit.py -m scanner -t example.com

# Save output to file
python3 kitploit.py -m scanner -t example.com -o results.txt

योगदान

हम योगदान का स्वागत करते हैं! कृपया सुनिश्चित करें कि आपने पहले CONTRIBUTING.md पढ़ लिया है।

1. रिपॉज़िटरी को फ़ोर्क करें
2. अपनी फ़ीचर ब्रांच बनाएं (git checkout -b feature/AmazingFeature)
3. अपने बदलाव कमिट करें (git commit -m 'Add some AmazingFeature')
4. ब्रांच पर पुश करें (git push origin feature/AmazingFeature)
5. एक पुल रिक्वेस्ट खोलें

लाइसेंस

यह प्रोजेक्ट MIT लाइसेंस के अंतर्गत वितरित किया गया है - विवरण के लिए LICENSE फ़ाइल देखें।

संपर्क

प्रोजेक्ट लिंक: https://github.com/example/kitploit```bash sudo ubuntils scan --json --baseline baseline.yaml

एक बेसलाइन प्रविष्टि `rule_id` के साथ-साथ एक `fingerprint` द्वारा मेल खाती है जिसे फाइंडिंग के `raw_value` के सबस्ट्रिंग के रूप में या उसके `artifact_path` के सटीक मिलान के रूप में परखा जाता है। एक मिलान फाइंडिंग को रिपोर्ट से पूरी तरह हटा देता है — हालांकि दमन कभी मौन नहीं होता: बेसलाइन द्वारा हटाई गई फाइंडिंग्स की संख्या हमेशा `scan_metadata.suppressed_by_baseline` में दिखाई देती है। Allowlist (`--config`) दमन अभी भी बेसलाइन दमन के ऊपर लागू होता है। `scan` और `analyze` दोनों पर समान रूप से काम करता है। एक नमूना [`examples/baseline.yaml`](https://github.com/asmitdesai/ubuntils/blob/main/examples/baseline.yaml) पर मौजूद है।

### कस्टम डिटेक्शन नियम (`--rules`)

`--config` फाइंडिंग्स को *दबाता* है; `--rules` उन्हें *जोड़ता* है। ये जानबूझकर अलग फाइलें हैं क्योंकि ये विपरीत चिंताएं हैं।

एक 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

| -s | --server | Server URL (default: http://localhost:8080) | | -t | --token | Authentication token | | -o | --output | Output file path | | -f | --format | Output format: json, yaml, csv | | -v | --verbose | Enable verbose logging | | -q | --quiet | Suppress non-error output | | | | Show help message |

उदाहरण

# Scan a single target
scanner -t example.com

# Scan multiple targets from a file
scanner -f targets.txt -o results.json

# Scan with authentication
scanner -t example.com --token "your-api-token"

# Scan with custom output format
scanner -t example.com -f csv -o results.csv

कॉन्फ़िगरेशन

The tool reads configuration from ~/.scanner/config.yaml:

server:
  url: "http://localhost:8080"
  timeout: 30

scan:
  threads: 10
  depth: 3
  exclude:
    - "*.example.com"
    - "internal.*"

API उपयोग

from scanner import Scanner

# Initialize the scanner
scanner = Scanner(server="http://localhost:8080", token="your-api-token")

# Run a scan
results = scanner.scan(target="example.com", depth=3)

# Process results
for finding in results.findings:
    print(f"[{finding.severity}] {finding.title}")

योगदान

We welcome contributions! Please follow these steps:

1. Fork the repository
2. Create a feature branch (git checkout -b feature/amazing-feature)
3. Commit your changes (git commit -m 'Add amazing feature')
4. Push to the branch (git push origin feature/amazing-feature)
5. Open a Pull Request

लाइसेंस

This project is licensed under the MIT License - see the LICENSE file for details.

आभार

• ProjectDiscovery for their amazing tools
• All contributors who have helped shape this project

नोट: This tool is intended for authorized security testing only. Always obtain proper permission before scanning any target.```bash sudo ubuntils scan --json --rules custom_rules.yaml

| `source` | इसके विरुद्ध मिलान किया जाता है |
|---|---|
| `cron` | cron कमांड (पथ: crontab फ़ाइल) |
| `environment` | कच्ची environment/shell-init पंक्ति (पथ: परिभाषित करने वाली फ़ाइल) |
| `ssh` | कुंजी प्रकार, कुंजी डेटा, और टिप्पणी (पथ: `authorized_keys` फ़ाइल) |
| `process` | प्रोसेस cmdline (पथ: exe पथ) |
| `network` | कनेक्शन विवरण (पथ: `remote_addr:remote_port`) |

`regex` और `substring` टेक्स्ट कॉलम से मेल खाते हैं; `glob` पथ कॉलम से मेल खाता है — इसलिए `203.0.113.*:*` जैसा `network` glob रिमोट एंडपॉइंट को लक्षित करता है। कस्टम-नियम निष्कर्ष केवल-फ़्लैग होते हैं (कभी स्वतः-उपचारित नहीं) और अभी भी `--config` दमन के अधीन हैं। एक नमूना [`examples/custom_rules.yaml`](https://github.com/asmitdesai/ubuntils/blob/main/examples/custom_rules.yaml) पर मौजूद है।

### रिपोर्ट अखंडता

प्रत्येक `--json` रिपोर्ट में एक `report_sha256` फ़ील्ड होता है — जो विहित रिपोर्ट सामग्री पर एक SHA-256 है। यह एकत्रित ट्राइएज आर्टिफ़ैक्ट को छेड़छाड़-स्पष्ट बनाता है और आपको केस फ़ाइल में डाइजेस्ट द्वारा किसी विशिष्ट स्कैन का संदर्भ देने की सुविधा देता है। रिपोर्ट `scan_metadata` के अंतर्गत `tool_version`, `hostname`, और एक UTC `generated_at` टाइमस्टैम्प भी रिकॉर्ड करती है। `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`, ताकि रिपोर्ट का चेन-ऑफ़-कस्टडी रिकॉर्ड विश्लेषक के वर्कस्टेशन के बजाय साक्ष्य का अनुसरण करे।

**रिपोर्ट का सत्यापन।** रिपोर्ट विहित रूप में उत्सर्जित की जाती है (कुंजियाँ क्रमबद्ध, 2-स्पेस इंडेंट), और डाइजेस्ट `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 के माध्यम से किसी माउंट किए गए इमेज के विरुद्ध, बिना रूट की आवश्यकता के और मूल होस्ट को दोबारा छुए बिना। यह उन मामलों के लिए है जहाँ आप आर्टिफैक्ट्स को एक बार प्राप्त करना चाहते हैं और उनका विश्लेषण बाद में, कहीं और, या बार-बार करना चाहते हैं — या जहाँ आप चल रहे सिस्टम के बजाय डिस्क इमेज का ट्राइएज कर रहे हैं।

`ubuntils collect````bash

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 और टेक्स्ट दोनों रूपों में, और पिछले 7 दिनों के लिए `journalctl -o json`), प्रत्येक कैप्चर किए गए आइटम को हैश करता है, और सब कुछ तथा एक `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]

यह या तो positional argument के रूप में bundle path लेता है या mounted image / extracted filesystem tree की ओर इंगित करने वाले --root PATH को — दोनों को नहीं। यह वही detection engine, custom rules, allowlist, और baseline logic चलाता है जो scan द्वारा उपयोग किए जाते हैं। इसके लिए root की आवश्यकता नहीं होती। Bundle को एक private temp directory में extract किया जाता है जिसे analysis पूरा होते ही delete कर दिया जाता है (इसमें /etc/shadow हो सकता है)।

दोनों offline modes के बीच coverage भिन्न होती है, क्योंकि एक bundle collect समय की replayed captured state ले जाता है जबकि --root के पास केवल वही होता है जो mounted filesystem पर मौजूद है:

• analyze BUNDLE collect समय पर captured वास्तविक ss/systemctl list-timers/journalctl command output को replay करता है, इसलिए NetworkCollector और SystemdCollector उस snapshot से वास्तविक findings उत्पन्न करते हैं — उन्हें skip नहीं किया जाता। Timeline उस syslog/messages/audit.log/journalctl से बनाई जाती है जिसे bundle ने capture किया, इसलिए यह पूरी तरह populated होती है और findings को वास्तविक related_events correlation मिलता है।
• analyze --root PATH एक dead, mounted image की ओर इंगित करता है जिसमें query करने के लिए कोई live process या kernel state नहीं होता, इसलिए command execution पूरी तरह disabled हो जाता है: NetworkCollector और SystemdCollector skip कर दिए जाते हैं, और scan_metadata.command_collectors_skipped में record किए जाते हैं। Timeline अभी भी बनाई जाती है, लेकिन image पर मौजूद static log files (, , ) से — journald replay यहाँ उपलब्ध नहीं है क्योंकि dead image को query करने के लिए कोई live नहीं है।

offline detection-coverage gaps की पूरी सूची के लिए Offline analysis: collect and analyze देखें।

Bundle format

एक bundle एक gzipped tarball होता है जिसमें सब कुछ bundle/ prefix के अंतर्गत होता है:``` 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 | प्रत्येक `collect` रन के लिए नया जनरेट किया गया UUID |
| `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 आउटपुट में बंडल इंटीग्रिटी

`analyze` का `scan_metadata.bundle_integrity` तीन में से एक मान रिपोर्ट करता है:

- `"live"` — `scan` और `analyze --root` यह रिपोर्ट करते हैं; सत्यापित करने के लिए कोई बंडल नहीं है।
- `"ok"` — `analyze BUNDLE` ने मैनिफ़ेस्ट के विरुद्ध `bundle_sha256` और प्रत्येक कैप्चर की गई फ़ाइल के SHA-256 को उसकी बंडल सामग्री के विरुद्ध सत्यापित किया; `collect` द्वारा इसे लिखे जाने के बाद से कुछ भी बदला नहीं गया है।
- `"mismatch"` — मैनिफ़ेस्ट डाइजेस्ट, किसी कैप्चर की गई फ़ाइल का हैश, या किसी कैप्चर किए गए कमांड आउटपुट का हैश मेल नहीं खाया। संग्रहण के बाद बंडल में कुछ संशोधित, ट्रंकेटेड, या करप्ट हो गया था, और इससे प्राप्त किसी भी चीज़ पर chain-of-custody-clean के रूप में भरोसा नहीं किया जाना चाहिए। `analyze` अभी भी अपनी रिपोर्ट बनाता है, लेकिन stderr पर एक लाल चेतावनी प्रिंट करता है, TUI Summary टैब के शीर्ष पर एक इंटीग्रिटी बैनर दिखाता है, और **status 3 के साथ बाहर निकलता है**, ताकि स्क्रिप्ट्स टैम्पर किए गए बंडल के परिणामों को आधिकारिक मानने की गलती न करें।

### ⚠️ ऑफ़लाइन विश्लेषण में वास्तविक डिटेक्शन गैप्स हैं — इस पर भरोसा करने से पहले यह पढ़ें

**बंडल- या `--root`-सोर्स्ड `analyze` रन में लाइव `scan` के साथ डिटेक्शन समानता नहीं होती।** ये एज केस नहीं हैं; ये स्टैटिक, ऑफ़लाइन अधिग्रहण की संरचनात्मक सीमाएँ हैं, और ये प्रभावित नियमों के लिए त्रुटि के बजाय कम (या शून्य) निष्कर्ष उत्पन्न करती हैं। जहाँ एक कलेक्टर *जानता* है कि वह देख नहीं सका (एक विफल कमांड, एक अपठनीय फ़ाइल), वह `scan_metadata.collectors_degraded` में दर्ज होता है और TUI Summary टैब में फ़्लैग किया जाता है — लेकिन जो फ़ाइल बस कैप्चर नहीं की गई वह उस फ़ाइल जैसी ही दिखती है जो मौजूद ही नहीं है। (टाइमलाइन अब इन गैप्स में से एक *नहीं* है: `analyze BUNDLE` `collect` समय से कैप्चर किए गए syslog/messages/audit.log/journalctl को रीप्ले करता है, और `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` की फ़ाइल सूची स्टैटिक है और `/etc/cron.d/*`, `/etc/sudoers.d/*`, `/etc/profile.d/*`, या प्रति-उपयोगकर्ता `~/.ssh/authorized_keys` को glob-एक्सपैंड नहीं कर सकती — केवल `/etc/crontab`, `/etc/sudoers`, और `/etc/environment`/`/etc/profile` कैप्चर किए जाते हैं। (`--root` पूर्ण माउंट किए गए फ़ाइलसिस्टम ट्री के विरुद्ध इस गैप से ग्रस्त नहीं है, क्योंकि वास्तविक डायरेक्टरीज़ डिस्क पर मौजूद होती हैं।) जब `SSH_UNAUTHORIZED_KEY` या `SHELL_RC_MODIFICATION` *फ़ायर* होते हैं (लाइव स्कैन, या वास्तविक प्रति-उपयोगकर्ता डायरेक्टरीज़ मौजूद होने पर `--root`), तो अब वे केवल mtime से नहीं, बल्कि ctime और फ़ाइल सामग्री से भी कॉन्फ़िडेंस स्कोर करते हैं — नीचे [Confidence scoring](#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` का उपयोग तब करें जब आपको एक बार अधिग्रहण करके कहीं और विश्लेषण करना हो, रूट के बिना विश्लेषण करना हो, या किसी डिस्क इमेज से काम कर रहे हों जहाँ `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.` दिखाता है।

### Findings टैब (कुंजी `2`)

सभी findings की एक स्क्रॉल करने योग्य सूची, जो HIGH → MEDIUM → LOW क्रम में क्रमबद्ध है। किसी finding का चयन करने पर (Enter या arrow keys) नीचे एक विस्तृत फलक खुलता है जिसमें पूरा विवरण, artifact path, कच्चा ट्रिगर करने वाला मान, और remediation जानकारी दिखाई जाती है।```
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

In-TUI उपचार

जिन findings के लिए स्वचालित उपचार उपलब्ध है, उनके लिए finding चयनित होने पर 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 — उपयोगकर्ता crontabs crontab स्वामी के रूप में चलते हैं। sudo या root-स्वामित्व वाले इंटरप्रेटर को आमंत्रित करने वाली प्रविष्टि का अर्थ है कि उपयोगकर्ता ने स्थायी sudo पहुँच की आवश्यकता के बिना, एक शेड्यूल पर root विशेषाधिकारों के साथ कोड चलाने की व्यवस्था की है। यह पासवर्ड परिवर्तनों से बच जाता है।

उदाहरण फ़ाइंडिंग:``` [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 job का अर्थ है कि किसी भी स्थायी पथ को छुए बिना invocations के बीच एक payload को बदला जा सकता है। यह `@reboot`/`@daily`-शैली की entries और `/etc/cron.{hourly,daily,weekly,monthly}` में मौजूद scripts को कवर करता है; उन scripts पर मिली findings केवल flag-only हैं, क्योंकि किसी shell script से एक पंक्ति हटाना कोई सुरक्षित स्वचालित समाधान नहीं है।

*उदाहरण finding:*```
[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` यूनिट, जो अधिक सामान्य persistence है और इसके लिए किसी टाइमर की आवश्यकता ही नहीं होती — जिसका ExecStart किसी temp डायरेक्टरी को संदर्भित करता है या ऐसी बाइनरी चलाता है जिसका स्वामी root नहीं है, हमलावर द्वारा बनाए गए persistence का संकेत है। Service यूनिट्स को सीधे unit डायरेक्टरियों से पढ़ा जाता है, जिसमें प्रति-उपयोगकर्ता `~/.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-दिन की विंडो हाल ही में जोड़ी गई कुंजियों को पकड़ती है, साथ ही पुराने सिस्टम पर प्रारंभिक प्रोविज़निंग से होने वाले शोर से बचती है। ध्यान दें: नियम फ़ाइल 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** — किसी मानव उपयोगकर्ता खाते (लॉगिन शेल वाले UID ≥ 1000) के लिए पासवर्ड-रहित sudo एक विशेषाधिकार उन्नयन वेक्टर है जो अन्य persistence तंत्रों को हटाने के बाद भी बना रहता है। वैध 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 से प्राप्त प्रक्रिया नाम का /proc/<pid>/exe से प्राप्त हल किए गए 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 पासवर्ड फ़ील्ड खाली है, उसका कोई पासवर्ड ही नहीं है, और Ubuntu का डिफ़ॉल्ट PAM स्टैक (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` में स्टेज किया गया एक executable जिसके पास एक established outbound socket है, HIGH है; एक वैध बाइनरी जो किसी non-standard remote port तक पहुँच रही है, MEDIUM है और देखने लायक है। यह वर्तमान स्थिति का एक स्नैपशॉट है, निरंतर निगरानी नहीं — जो beacon आपके स्कैन करते समय सो रहा हो, वह दिखाई नहीं देगा। केवल-फ़्लैग।

*उदाहरण निष्कर्ष:*```
[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 — शेल init फ़ाइलें एक विश्वसनीय persistence vector हैं क्योंकि वे हर उपयोगकर्ता लॉगिन पर निष्पादित होती हैं। यह नियम मानवीय समीक्षा के लिए हाल के संशोधनों को सामने लाता है। केवल-फ़्लैग — शेल RC सामग्री पर कार्रवाई करने से पहले उसे पढ़ना आवश्यक है।

उदाहरण निष्कर्ष:``` [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` का उपयोग करके सामग्री/मोड/आकार में बेमेल हो। केवल-Conffile संपादन (अपेक्षित स्थानीय कॉन्फ़िगरेशन परिवर्तन) को शोर से बचने के लिए रिपोर्टिंग से बाहर रखा गया है। केवल-फ़्लैग — छेड़छाड़ वैध (कस्टम स्थानीय संपादन) या दुर्भावनापूर्ण (फ़ाइल प्रतिस्थापन) हो सकती है; निर्णय लेने के लिए मानवीय निर्णय की आवश्यकता होती है।

*उदाहरण निष्कर्ष:*```
[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 — हमलावर अक्सर फ़ाइलों को संशोधन या विलोपन से बचाने के लिए immutable flag (i) या append-only flag (a) सेट करते हैं, यहाँ तक कि root द्वारा भी, जिसमें आगे के संपादनों/लॉग रोटेशन से छेड़छाड़ को छिपाना भी शामिल है। संवेदनशील सिस्टम फ़ाइलों जैसे /etc/passwd, /etc/sudoers, /etc/pam.d/*, या auth/syslog/wtmp/btmp लॉग फ़ाइलों पर इन फ़्लैग्स को सेट करना हमलावर द्वारा hardening का एक मजबूत संकेतक है। यह नियम संवेदनशील पथों की उस निश्चित सूची के विरुद्ध lsattr के माध्यम से immutable और append-only फ़्लैग्स का पता लगाता है। केवल-फ़्लैग — फ़्लैग परिवर्तनों के लिए मानवीय समीक्षा आवश्यक है।

उदाहरण निष्कर्ष:``` [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 (Pluggable Authentication Modules) और NSS (Name Service Switch) Linux पर मुख्य प्रमाणीकरण और पहचान प्रणालियाँ हैं। यह नियम mtime-आधारित "क्या यह फ़ाइल संशोधित की गई थी" पहचान नहीं करता — यह फ़ाइल *सामग्री* का पैटर्न-मिलान करता है: (1) किसी भी /etc/pam.d/* फ़ाइल में एक शाब्दिक `pam_permit.so` पंक्ति (यह मॉड्यूल हमेशा सफल होता है और एक क्लासिक auth-bypass backdoor है), या (2) /etc/nsswitch.conf में सूचीबद्ध एक NSS मॉड्यूल जो ubuntils की अंतर्निहित allowlist में नहीं है। **नोट:** NSS जाँच डोमेन-जॉइंड/SSSD/LDAP/Winbind होस्ट्स पर अंतर्निहित allowlist के बाहर के मॉड्यूल का उपयोग करने पर false-positive देगी — इस कारण से इसे जानबूझकर pam_permit.so मिलान की तुलना में कम विश्वास पर स्कोर किया गया है; अपने वातावरण के लिए अपरिचित मॉड्यूल नामों को allowlist करने के लिए `--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 — कर्नेल मॉड्यूल ring 0 में अप्रतिबंधित पहुँच के साथ चलते हैं। हमलावर अक्सर rootkits, packet sniffing, या process hiding के लिए कस्टम कर्नेल मॉड्यूल लोड करते हैं। यह नियम वर्तमान में लोड किए गए मॉड्यूल की तुलना अपेक्षित built-in मॉड्यूल की एक छोटी allowlist (जो अधिकांश सिस्टमों में सामान्य है) से करता है। यह LOW severity का है क्योंकि वह allowlist जानबूझकर संकीर्ण है। नोट: GPU drivers, Wi-Fi cards, या proprietary drivers वाले hardware-heavy hosts false positives उत्पन्न करेंगे। Responders को चाहिए कि वे अपने host के अपेक्षित मॉड्यूल --config के माध्यम से जोड़ें, मॉड्यूल नाम (जो artifact_path के रूप में उपयोग होता है) से allowlisting करें। Flag-only — कर्नेल मॉड्यूल जाँच के लिए forensic tools और मानवीय विशेषज्ञता आवश्यक है।

उदाहरण finding:``` [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, या विश्व-लेखन-योग्य अस्थायी निर्देशिका)। यह नियम `/usr /bin /sbin /opt /home /srv /tmp /var/tmp /dev/shm` में `find -perm -4000 -o -perm -2000` के माध्यम से setuid/setgid बाइनरीज़ की सूची बनाता है और वैध सिस्टम उपयोगिताओं के ज्ञात बेसलाइन सेट के बाहर किसी भी बाइनरी को चिह्नित करता है। केवल-चिह्नित — अप्रत्याशित setuid/setgid बाइनरीज़ की जाँच आवश्यक है लेकिन ये एप्लिकेशन-इंस्टॉल की गई वैध बाइनरीज़ हो सकती हैं।

*उदाहरण निष्कर्ष:*```
[LOW] SETUID_INVENTORY
Title:         Unexpected setuid binary
Artifact:      /tmp/.hidden/backdoor
Raw value:     setuid
Remediation:   not available

JSON आउटपुट

--json stdout पर एक एकल JSON ऑब्जेक्ट लिखता है। इसके अलावा कुछ भी प्रिंट नहीं होता।```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` `scan` और `analyze --root` के लिए `"live"` होता है, `analyze` को पास किए गए सत्यापित बंडल के लिए `"ok"` होता है, और `"mismatch"` होता है यदि किसी बंडल की सामग्री उसके मैनिफ़ेस्ट से मेल नहीं खाती — देखें [Bundle integrity in JSON output](#bundle-integrity-in-json-output)। `scan_metadata.command_collectors_skipped` किसी भी कमांड-आधारित कलेक्टर (`NetworkCollector`, `SystemdCollector`, `PackageCollector`, `KernelCollector`) का नाम बताता है जो `--root` रन के लिए छोड़े गए — `scan` और `analyze BUNDLE` के लिए हमेशा खाली। `scan_metadata.suppressed_by_baseline` उन findings की संख्या है जिन्हें `--baseline` फ़ाइल ने इस रिपोर्ट से हटा दिया — देखें [Known-good baselining](#known-good-baselining---baseline)। `scan_metadata.collectors_degraded` एक कलेक्टर नाम को उन कारणों से मैप करता है जिनसे उसका डेटा अधूरा है (एक कमांड जो विफल हुआ या टाइम आउट हो गया, एक अपठनीय फ़ाइल, एक छोड़ी गई विकृत पंक्ति), `rules_failed` किसी भी डिटेक्शन रूल को सूचीबद्ध करता है जो क्रैश हुआ, और `timeline_error` सेट होता है यदि टाइमलाइन बनाई नहीं जा सकी। एक स्वस्थ रन पर तीनों खाली होते हैं। खाली findings सूची को "clean" पढ़ने से पहले इन्हें जाँचें।

`related_events` और `guided_remediation` किसी finding पर केवल तब प्रकट होते हैं जब उनमें सामग्री हो। `related_events` में आर्टिफ़ैक्ट पथ और रूल कीवर्ड द्वारा finding से मेल खाते अधिकतम पाँच टाइमलाइन इवेंट होते हैं, सबसे हाल का पहले — एक सरफेसिंग सहायता, कारणात्मक दावा नहीं। `guided_remediation` एक समीक्षित कमांड अनुक्रम है जिसे आपको हाथ से चलाना है; ubuntils इसे कभी निष्पादित नहीं करता।

### Confidence scoring

प्रत्येक finding में एक `confidence` स्कोर (0–100, डिफ़ॉल्ट 50) और एक `confidence_band` (`HIGH` ≥ 75, `MEDIUM` ≥ 40, उससे नीचे `LOW`) होता है, साथ ही एक `signals` सूची जो दिखाती है कि वह स्कोर वास्तव में कैसे प्राप्त हुआ — प्रत्येक प्रविष्टि `{"name", "weight", "detail"}` है, इसलिए स्कोर हमेशा व्याख्येय होता है, कभी ब्लैक बॉक्स नहीं। Signals 50 के आधार confidence के ऊपर योगात्मक होते हैं और जिस भी रूल या पाइपलाइन चरण ने उन्हें उत्पन्न किया, उसके द्वारा लागू किए जाते हैं:

- Detection rules finding के समय अपने स्वयं के signals लागू करते हैं — उदाहरण के लिए `SSH_UNAUTHORIZED_KEY` और `SHELL_RC_MODIFICATION` `content_match` (+30) जोड़ते हैं जब आर्टिफ़ैक्ट की सामग्री किसी ज्ञात-खतरनाक पैटर्न से मेल खाती है (एक खतरनाक SSH key विकल्प; एक shell RC फ़ाइल में curl/wget-to-shell या base64-decode पंक्ति), `ctime_corroborates_mtime` (+20) जब फ़ाइल का ctime भी डिटेक्शन विंडो के भीतर हो (अकेले mtime की तुलना में नकली बनाना कठिन), या `mtime_only` (−20) जब recency *एकमात्र* signal हो और ctime उसकी पुष्टि न करे — एक संकेत कि mtime को पीछे की तारीख का बनाया गया हो सकता है।
- पाइपलाइन finding↔timeline correlation के बाद `timeline_corroboration` (+25) लागू करती है, जब किसी finding में एक या अधिक `related_events` हों।

`LOW`-band finding को खारिज या छिपाया नहीं जाता — यह findings सूची और JSON आउटपुट में किसी भी अन्य की तरह ही प्रकट होता है — लेकिन band आपको बताता है कि आगे जाँच करने से पहले उस पर कितना भार डालना है। यह `SSH_UNAUTHORIZED_KEY`/`SHELL_RC_MODIFICATION` के लिए पुराने mtime-only heuristic को प्रतिस्थापित करता है, जहाँ एक पुरानी लेकिन वैध रूप से छुई गई फ़ाइल (उदाहरण के लिए एक config management tool जो हर रन पर `.bashrc` को फिर से लिखता है) एक वास्तविक नए backdoor के समान दिखती थी।

**Known limitation:** आज केवल content-pattern और ctime signals ही लाइव हैं। Ownership/fingerprint-आधारित signals — एक अज्ञात SSH key fingerprint, एक key का `from=` प्रतिबंध विकल्प, या एक RC-file owner/mode बेमेल (एक `ownership_anomaly` signal) — अभी तक लागू नहीं हैं। यह एक स्थगित coverage gap है, भविष्य के रिलीज़ के लिए ट्रैक किया गया, ऐसा कुछ नहीं जिसे वर्तमान confidence स्कोर ध्यान में रखता हो।

---

## Remediation

सोलह detection rules में से पाँच में स्वचालित remediation है: `CRON_ROOT_EXEC`, `CRON_TMP_PATH`, `LD_PRELOAD_INJECT`, `SSH_UNAUTHORIZED_KEY`, और `SUDOERS_NOPASSWD`। शेष flag-only हैं और कभी auto-remediated नहीं होंगे, क्योंकि उन पर सुरक्षित रूप से कार्य करने के लिए पहले एक मानव को देखने की आवश्यकता होती है।

### Guided remediation

`SUSPICIOUS_SYSTEMD_TIMER`, `PROCESS_MASQUERADE`, और `SHELL_RC_MODIFICATION` में एक `guided_remediation` स्ट्रिंग होती है: finding की पुष्टि करने के बाद चलाने के लिए सटीक कमांड — `systemctl disable --now <unit>`, `kill -9 <pid>`, या RC-file की समीक्षा और वापसी। यह TUI detail pane और JSON में दिखता है। ubuntils इसे आपके लिए कभी नहीं चलाता; ये rules डिज़ाइन के अनुसार `--remediate --confirm` sweep से बाहर रहते हैं।

### TUI में

Findings टैब में remediation वाले किसी भी finding को चुनें, फिर `R` दबाएँ। एक confirmation modal नियोजित कार्रवाई का पूर्वावलोकन करता है। इसे लागू करने के लिए `Y` दबाएँ — remediator एक background thread में चलता है ताकि TUI उत्तरदायी बना रहे। पूरा होने पर finding पंक्ति `[fixed]` में अपडेट हो जाती है, साथ में backup path और सटीक rollback कमांड इनलाइन दिखाए जाते हैं।

### CLI से

`--confirm` के बिना `--remediate` एक सुरक्षित dry run है: backups बनाए जाते हैं और validation चलती है, लेकिन कोई परिवर्तन लागू नहीं होते। वास्तव में परिवर्तन करने के लिए दोनों flags पास करें। इस मोड में पाइपलाइन TUI लॉन्च होने से पहले चलती है, और Summary टैब प्रत्येक remediation परिणाम को उसके backup path और rollback कमांड के साथ सूचीबद्ध करता है।

`--remediate --confirm` केवल कम से कम 40 (MEDIUM band) के confidence स्कोर वाले findings पर कार्य करता है — एक low-confidence, mtime-only `SSH_UNAUTHORIZED_KEY` को उसकी key हटाने के बजाय `SKIPPED` के रूप में रिपोर्ट किया जाता है। `--min-confidence N` के साथ gate समायोजित करें।```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

सुरक्षा उपाय

प्रत्येक उपचार समान पैटर्न का पालन करता है, चाहे वह किसी भी तरह से ट्रिगर हो:

1. पता लगाएं कि क्या आर्टिफैक्ट पथ एक सिमलिंक है — यदि हां, तो मना करें (हमलावर-नियंत्रित सिमलिंक के माध्यम से रूट लेखन को रोकता है)
2. /var/backups/ubuntils/YYYYMMDD_HHMMSS/ पर मोड 0700 के साथ एक टाइमस्टैम्प्ड बैकअप बनाएं
3. वर्तमान स्थिति को मान्य करें (सटीक पंक्ति अभी भी मौजूद होनी चाहिए)
4. न्यूनतम संभव परिवर्तन लागू करें — क्रॉन प्रविष्टियां और कुंजियां पंक्ति दर पंक्ति हटा दी जाती हैं; शेल इनिट फ़ाइलों में LD_PRELOAD पंक्तियों को टिप्पणी कर दिया जाता है; /etc/ld.so.preload में प्रविष्टियां हटा दी जाती हैं (लोडर में वहां कोई टिप्पणी सिंटैक्स नहीं है, इसलिए एक टिप्पणी की गई प्रविष्टि अभी भी लोड होगी)। sudoers के लिए, संपादित सामग्री को वास्तविक फ़ाइल को छूने से पहले एक अस्थायी प्रति पर visudo -cf के साथ जांचा जाता है
5. परमाणु रूप से लिखें — नई सामग्री मूल के बगल में एक अस्थायी फ़ाइल में जाती है (समान मोड और स्वामी), fsync'd है, फिर उसके ऊपर नाम बदल दिया जाता है, ताकि लेखन के बीच में क्रैश एक काटे गए /etc/sudoers को पीछे न छोड़ सके
6. सत्यापित करें कि सटीक पंक्ति चली गई है

यदि कोई भी चरण विफल हो जाता है, तो उपचार तुरंत रुक जाता है, सिस्टम अपरिवर्तित छोड़ दिया जाता है, और पूरी त्रुटि बैकअप पथ और रोलबैक कमांड के साथ रिपोर्ट की जाती है। Sudo पहुंच दो तरह से सुरक्षित है: %group NOPASSWD नियम (जैसे %sudo) केवल-फ्लैग हैं और कभी स्वतः नहीं हटाए जाते, और sudoers उपचारक मुख्य sudoers फ़ाइल से अंतिम नियम को हटाने से इनकार करता है।

Wazuh एकीकरण

ubuntils एकल-होस्ट, बिंदु-इन-टाइम ट्राइएज के लिए बनाया गया है — आप इसे तब चलाते हैं जब आपको पहले से संदेह होता है कि कुछ गलत है, और यह कभी घर फोन नहीं करता या स्कैन समाप्त होने के बाद निगरानी नहीं रखता। यह जानबूझकर है, लेकिन इसका मतलब यह भी है कि ubuntils से एक निष्कर्ष केवल उस एक रिपोर्ट में रहता है जब तक कि कुछ इसे आगे नहीं ले जाता। किसी भी पैमाने पर Ubuntu चलाने वाली अधिकांश टीमों के पास पहले से ही एक SIEM होता है जो पहचान का निरंतर पक्ष कर रहा है, इसलिए ubuntils को अपने स्वयं के लंबे समय तक चलने वाले निगरानी एजेंट में बनाने के बजाय, यह अपने निष्कर्षों को उस एक को सौंप देता है जो आप संभवतः पहले से चलाते हैं: Wazuh।

यदि होस्ट पर एक Wazuh एजेंट मौजूद है (/var/ossec/bin/wazuh-agentd या /var/ossec/etc/ossec.conf मौजूद है), तो ubuntils scan (--no-wazuh के साथ चलाए जाने तक) प्रत्येक निष्कर्ष को एजेंट द्वारा उठाने के लिए /var/log/ubuntils/wazuh-alerts.json में एक JSON पंक्ति के रूप में जोड़ता है — यह एक शुद्ध फॉरवर्डर है, Wazuh मॉड्यूल नहीं: कोई नेटवर्क कॉल नहीं, कोई API कुंजी नहीं, कुछ भी नहीं बल्कि वही स्थानीय आर्टिफैक्ट लेखन जो ubuntils पहले से करता है — हालांकि एजेंट निश्चित रूप से उन पंक्तियों को अपने प्रबंधक को ऑफ-होस्ट भेज देगा; यही बात है। यह स्वतः पता लगाया जाता है और किसी फ्लैग की आवश्यकता नहीं होती (किसी रन को ऑप्ट आउट करने के लिए --no-wazuh का उपयोग करें), इसलिए एजेंट-नामांकित होस्टों के फ्लीट पर एक स्क्रिप्टेड या शेड्यूल्ड ubuntils scan बिना किसी अतिरिक्त वायरिंग के तुरंत SIEM को फीड करना शुरू कर देता है। यह ऑफ़लाइन ubuntils analyze (बंडल या --root) के दौरान कभी नहीं होता, क्योंकि वे निष्कर्ष स्थानीय Wazuh एजेंट चलाने वाले होस्ट से भिन्न होस्ट का वर्णन करते हैं — एक बंडल के निष्कर्षों को विश्लेषक के अपने एजेंट को अग्रेषित करना उन्हें गलत मशीन के लिए गलत तरीके से जिम्मेदार ठहराएगा।

इरादा ubuntils को एक मौजूदा अलर्टिंग/एस्केलेशन पाइपलाइन में शामिल करना है, बजाय एक प्रतिक्रियाकर्ता से दूसरे उपकरण की देखभाल करने के लिए कहने के: एक बार नीचे दिए गए उदाहरण नियम लोड हो जाने के बाद, एक HIGH-गंभीरता वाला ubuntils निष्कर्ष (एक नया UID-0 खाता, एक LD_PRELOAD रूटकिट, एक PAM बैकडोर) एक सामान्य Wazuh अलर्ट के रूप में दिखाई देता है, प्रबंधक के पास पहले से कॉन्फ़िगर किए गए किसी भी अधिसूचना रूटिंग को विरासत में लेता है, और एक स्टैंडअलोन JSON फ़ाइल के बजाय जिसे किसी को जांचना याद रखना होता है, उसी टाइमलाइन में हर अन्य सिग्नल के साथ बैठता है।

Wazuh को इन निष्कर्षों को पार्स करने और अलर्ट करने के लिए, examples/wazuh/ से उदाहरण नियमों को अपने Wazuh प्रबंधक पर कॉपी करें, और examples/wazuh/ossec_localfile_snippet.xml से <localfile> ब्लॉक को एजेंट के /var/ossec/etc/ossec.conf में जोड़ें। किसी कस्टम डिकोडर इंस्टॉल की आवश्यकता नहीं है: localfile को log_format json के साथ कॉन्फ़िगर किया गया है, इसलिए Wazuh का अंतर्निहित JSON डिकोडर प्रत्येक पंक्ति को पार्स करता है और प्रत्येक शीर्ष-स्तरीय JSON कुंजी k को data.k पर मैप करता है, जिसे local_rules.xml सीधे मैच करता है।

1. examples/wazuh/local_rules.xml → प्रबंधक का /var/ossec/etc/rules/
2. examples/wazuh/ossec_localfile_snippet.xml का <localfile> ब्लॉक → एजेंट का /var/ossec/etc/ossec.conf
3. दोनों को पुनः आरंभ करें: systemctl restart wazuh-manager (प्रबंधक), systemctl restart wazuh-agent (एजेंट होस्ट)

ये केवल उदाहरण टेम्पलेट हैं, जो एक प्रारंभिक बिंदु के रूप में प्रदान किए गए हैं — इन्हें लाइव Wazuh प्रबंधक के विरुद्ध परीक्षण नहीं किया गया है और इन पर भरोसा करने से पहले गैर-उत्पादन वातावरण में सत्यापित किया जाना चाहिए।

प्रति पंक्ति JSON स्कीमा:

कलेक्टर

कलेक्टर निर्भरताएँ

PackageCollector को लाइव होस्ट पर तीन मानक Ubuntu उपकरणों की आवश्यकता होती है (dpkg, lsattr, find — सभी स्टॉक Ubuntu इंस्टॉलेशन पर मौजूद)। यदि कोई कमांड अनुपलब्ध है, तो PackageCollector क्रैश होने के बजाय उस भाग के लिए शालीनता से खाली डेटा उत्पन्न करता है। ऑफ़लाइन विश्लेषण (analyze BUNDLE) collect समय से कैप्चर किए गए कमांड आउटपुट को रीप्ले करता है, इसलिए विश्लेषक के होस्ट पर कमांड उपलब्धता की आवश्यकता नहीं है।

setuid/setgid find स्कैन सीमित रहने के लिए -xdev पास करता है — यह अलग से माउंट किए गए फ़ाइलसिस्टम में नहीं उतरता (/opt के अंतर्गत एक अलग माउंट, एक NFS-माउंटेड /home, आदि)। यह एक जानबूझकर रनटाइम-बनाम-कवरेज ट्रेडऑफ है: -xdev के बिना, स्कैन नेटवर्क माउंट या वर्चुअल फ़ाइलसिस्टम को स्कैन करते समय हैंग हो सकता है। यदि आपका वातावरण इन पथों को अलग फ़ाइलसिस्टम पर माउंट करता है, तो ध्यान रखें कि वे स्कैन नहीं किए जाएंगे।

dpkg --verify और setuid/setgid find स्कैन उदार गैर-डिफ़ॉल्ट टाइमआउट का उपयोग करते हैं (क्रमशः 10 मिनट और 5 मिनट, ubuntils/collectors/packages.py देखें) क्योंकि दोनों वास्तव में एक बड़े पैकेज डेटाबेस या फ़ाइलसिस्टम ट्री वाले वास्तविक होस्ट पर लाइब्रेरी डिफ़ॉल्ट 30 सेकंड से काफी अधिक चल सकते हैं; ubuntils collect इन कमांडों को एक बंडल में कैप्चर करते समय समान टाइमआउट का उपयोग करता है।

संगतता

रूट के बिना चलाने से चेतावनियों के साथ आंशिक स्कैन उत्पन्न होता है। /etc/shadow, संरक्षित crontab निर्देशिकाएं, और कुछ /proc प्रविष्टियों जैसे महत्वपूर्ण पथ छोड़ दिए जाएंगे।

रोडमैप

v1.0.0

• सभी 8 कलेक्टर
• सभी 8 डिटेक्शन नियम
• टाइमलाइन बिल्डर (syslog, journald, auditd)
• प्रति-कलेक्टर ✓/✗ के साथ लाइव स्कैन प्रगति स्क्रीन
• इंटरैक्टिव चार-टैब TUI (Summary / Findings / Timeline / Stats)
• पुष्टि मोडल और बैकग्राउंड वर्कर के साथ TUI में उपचार
• JSON आउटपुट मोड
• बैकअप, रोलबैक, और सिमलिंक गार्ड के साथ 5 नियमों के लिए CLI उपचार
• Ubuntu 20.04/22.04/24.04 समर्थन
• 90% कवरेज पर 240 परीक्षण

v1.1.0

• नियम id या पथ द्वारा गलत-सकारात्मक अनुमति सूची (--config)
• रिपोर्ट सीधे लिखने के लिए --output FILE
• --since टाइमलाइन विंडोइंग
• छेड़छाड़-स्पष्ट रिपोर्ट (report_sha256, hostname, timestamp)
• USER_UID_ZERO डिटेक्शन नियम

v1.5.0

• YAML के माध्यम से कस्टम पैटर्न-मैच डिटेक्शन नियम (--rules)
• PROCESS_SUSPICIOUS_CONNECTION — PID द्वारा प्रक्रिया↔नेटवर्क सहसंबंध
• स्वचालित निष्कर्ष↔टाइमलाइन सहसंबंध (related_events)
• तीन निर्णय-आवश्यक नियमों के लिए निर्देशित उपचार
• 92% कवरेज पर 282 परीक्षण

VirusTotal हैश लुकअप और MISP IOC निर्यात इस रिलीज़ से हटा दिए गए थे। VirusTotal केवल ज्ञात हैश के लिए उत्तर देता है — वह मामला जिसे rkhunter पहले से कवर करता है, और ubuntils जिस नई-तकनीक अंतराल को लक्षित करता है उसके विपरीत — और दोनों सुविधाएँ एक ऐसे उपकरण के अंदर नेटवर्क कॉल डाल देतीं जिसका मूल्य कोई न करने में निहित है। ubuntils स्वयं अभी भी कोई नेटवर्क कॉल नहीं करता (होस्ट छोड़ने के एक ऑप्ट-आउट-योग्य तरीके के लिए Wazuh एकीकरण देखें, एक स्थानीय एजेंट के माध्यम से)।

v2.0.0 — ऑफ़लाइन collect/analyze विभाजन

• ubuntils collect — एक लाइव होस्ट से छेड़छाड़-स्पष्ट बंडल (manifest.json + हैश्ड फ़ाइलें/कमांड) प्राप्त करता है, कोई डिटेक्शन नहीं
• ubuntils analyze (BUNDLE | --root PATH) — एक बंडल या माउंटेड इमेज के विरुद्ध scan के समान डिटेक्शन/टाइमलाइन पाइपलाइन चलाता है, रूट की आवश्यकता नहीं
• scan_metadata में bundle_integrity (live/ok/mismatch) प्रदर्शित
• ऑफ़लाइन मोड में प्रलेखित डिटेक्शन-कवरेज अंतराल (PROCESS_MASQUERADE, PROCESS_SUSPICIOUS_CONNECTION, और cron/sudoers/SSH ग्लोब पथों और systemd टाइमर के लिए कम कवरेज)

v2.1.0 — SIEM अग्रेषण

• लाइव ubuntils scan निष्कर्ष JSONL के रूप में एक स्थानीय Wazuh एजेंट को अग्रेषित, स्वतः पता लगाया गया (किसी फ्लैग की आवश्यकता नहीं)
• उदाहरण Wazuh डिकोडर/नियम और ossec.conf <localfile> स्निपेट (examples/wazuh/)
• अग्रेषण जानबूझकर केवल लाइव scan तक सीमित — ऑफ़लाइन analyze के दौरान कभी नहीं चलता, क्योंकि एक बंडल या इमेज एजेंट चलाने वाले होस्ट से भिन्न होस्ट का वर्णन करता है
• एक स्कैन को अग्रेषण से ऑप्ट आउट करने के लिए --no-wazuh

v2.1.0 — हार्डनिंग (पूर्ण-कोडबेस ऑडिट)

• सुरक्षा: sudo re-exec अब कॉलर के PATH को अग्रेषित नहीं करता, और कमांड एक निश्चित सुरक्षित पथ पर हल होते हैं; sudoers संपादन फ़ाइल को छूने से पहले visudo-जांचे जाते हैं; परमाणु उपचार लेखन; सिमलिंक-सुरक्षित रिपोर्ट/बंडल आउटपुट; analyze के बाद निकाले गए बंडल हटा दिए जाते हैं
• डिटेक्शन कवरेज: /etc/ld.so.preload पार्स किया गया, @reboot/@daily cron प्रविष्टियां और /etc/cron.{hourly,daily,weekly,monthly} स्क्रिप्ट, systemd .service इकाइयां और गैर-रूट-स्वामित्व वाली ExecStart बाइनरी, %group sudoers नियम और #include/@includedir, एक LD_PRELOAD सूची का प्रत्येक तत्व

v3.0.0 / v4.0.0 (खोजपूर्ण)

• मल्टी-होस्ट ट्राइएज के लिए वेब डैशबोर्ड
• macOS समर्थन

योगदान

इस समय सबसे उपयोगी योगदान हैं नए डिटेक्शन नियम (एक मिलान परीक्षण के साथ detectors/rules.py में स्टैंडअलोन फ़ंक्शन के रूप में जोड़े गए), अभी तक कवर नहीं किए गए आर्टिफैक्ट प्रकारों के लिए अतिरिक्त कलेक्टर, SUSPICIOUS_SYSTEMD_TIMER और SHELL_RC_MODIFICATION के लिए उपचार मॉड्यूल (दोनों वर्तमान में डिज़ाइन द्वारा केवल-फ्लैग हैं, लेकिन सुरक्षित ऑटो-उपचार पथ मौजूद हो सकते हैं), विशिष्ट Ubuntu कॉन्फ़िगरेशन पर एज केस के लिए परीक्षण मामले, और दस्तावेज़ीकरण सुधार।

बड़े योगदान को शुरू करने से पहले एक इश्यू खोलें ताकि डुप्लिकेट काम से बचा जा सके।

लाइसेंस

MIT

लेखक

Asmit द्वारा निर्मित — BTech Computer Science, PES University, Bengaluru। यह उपकरण इस निराशा से निकला कि मैनुअल Ubuntu ट्राइएज में कितना समय लगता है, इसकी तुलना में कि एक अच्छी तरह से स्कोप किया गया स्क्रिप्ट क्या स्वचालित कर सकता है।