ubuntils

Python-CLI/TUI für die forensische Triage von Ubuntu-Systemen — erkennt und behebt Persistenzmechanismen mit Artefakterfassung, Zeitachsenkorrelation und Wazuh-Integration.

Wenn Sie vermuten, dass ein Linux-System kompromittiert wurde, werden die ersten 30-40 Minuten üblicherweise damit verbracht, dieselben zehn Befehle nacheinander auszuführen: laufende Prozesse prüfen, nach seltsamen Cron-Jobs suchen, nach LD_PRELOAD greppen, authorized_keys auf neue Einträge scannen, sudoers auditieren. Jeder Schritt ist manuell, erfordert Kontextwechsel und ist unter Druck fehleranfällig. Verpassen Sie eine Quelle — etwa /etc/sudoers.d/ statt nur /etc/sudoers, oder Benutzer-Crontabs zusätzlich zu /etc/cron.d/ — und Sie haben ein unvollständiges Bild.

Bestehende Optionen lösen dies nicht sauber. lynis ist ein Härtungs-Auditor, kein Triage-Tool — es meldet Konfigurationsschwächen auf einem sauberen System und erzeugt Rauschen auf einem kompromittierten. chkrootkit und rkhunter prüfen auf bekannte Rootkit-Signaturen, sind aber blind für neuartige Persistenztechniken wie missbrauchte systemd-Timer oder legitim aussehende Cron-Einträge. Generische SIEM-Abfragen erfordern eine Log-Infrastruktur, die auf dem betrachteten System möglicherweise nicht existiert. Und Forensik-Suiten wie Volatility zielen auf Speicherabbilder ab, nicht auf eine Live-Shell auf einem laufenden Host.

Die Lücke ist ein Tool, das jetzt gerade auf dem laufenden System läuft, die gängigsten Persistenzvektoren abdeckt, Aktivitäten über Log-Quellen hinweg zu einer Timeline korreliert und Ihnen genau sagt, was Sie sich ansehen müssen — ohne einen externen Agenten, eine Datenbank oder eine Internetverbindung zu benötigen.

Was ubuntils tut

ubuntils läuft in vier aufeinanderfolgenden Phasen:

1. Erfassung — Elf Collector sammeln forensische Artefakte gleichzeitig aus /proc, Cron-Tabellen, systemd-Units, SSH-Schlüsseln, sudoers-Dateien, Umgebungsdefinitionen, Paketintegrität (dpkg --verify), PAM/NSS-Konfiguration und geladenen Kernelmodulen. Dauert auf einem typischen System etwa 2,5 Sekunden.
2. Erkennung — Eine Erkennungs-Engine führt alle sechzehn integrierten Regeln — plus alle mit --rules geladenen benutzerdefinierten Regeln — über die gesammelten Artefakte aus und erzeugt in etwa einer Sekunde eine priorisierte, mit Konfidenzwerten versehene Befundliste.
3. Timeline — Ein Timeline-Builder liest syslog, journald und auditd parallel und korreliert Ereignisse chronologisch, was etwa 0,3 Sekunden hinzufügt. Jeder Befund wird dann automatisch gegen die Timeline korreliert, sodass er die nahegelegenen Ereignisse trägt, die mit ihm zusammenhängen.
4. Ausgabe — Ergebnisse erscheinen entweder in einer interaktiven TUI mit vier Tabs (Standard) oder als strukturiertes JSON auf stdout (--json).

ubuntils selbst führt keine Netzwerkaufrufe durch, und jede Funktion — benutzerdefinierte Regeln und Korrelation eingeschlossen — läuft gegen lokal gesammelte Artefakte. Die einzige Möglichkeit, wie Befunde den Host verlassen können, ist die Wazuh-Integration: Wenn ein Wazuh-Agent installiert ist, schreibt ein Live-scan seine Befunde in eine lokale Datei, die der Agent dann an seinen Manager übermittelt. Übergeben Sie --no-wazuh, um das für einen Lauf abzuschalten.

ubuntils scan ist durch alles Folgende unverändert — es ist weiterhin 100 % live, Single-Host, und jeder bestehende Flag funktioniert identisch. Zwei zusätzliche Befehle, collect und analyze, teilen dieselbe Erkennungs-/Timeline-Pipeline in einen offline-freundlichen Acquire-then-Analyze-Workflow für Fälle auf, in denen Sie die Erkennung nicht direkt auf dem untersuchten Host ausführen können (oder wollen) — siehe Offline-Analyse: collect und analyze unten, einschließlich der Einschränkungen zur Erkennungsabdeckung.

Installation

Ubuntu 22.04+ und jedes System mit PEP 668 (empfohlen):

Ubuntu 22.04+ blockiert systemweites pip install. Verwenden Sie pipx — es handhabt die Umgebung transparent, sodass Sie nie darüber nachdenken müssen:```bash sudo apt install pipx -y cd ubuntils pipx install -e . ubuntils scan

ubuntils benötigt Root-Rechte für den vollständigen Zugriff auf Artefakte. Wenn du ubuntils scan als Nicht-Root-Benutzer ausführst, ruft es sich automatisch selbst mit sudo unter Verwendung desselben Python-Interpreters (über absoluten Pfad) erneut auf, sodass die korrekte Umgebung verwendet wird, ohne deinen PATH an den Root-Prozess weiterzugeben. Jeder externe Befehl (ss, dpkg, systemctl, …) wird über einen festen, root-eigenen Suchpfad aufgelöst, niemals über deinen PATH. Wenn du ohne Root ausgeführt wirst, werden /etc/shadow, einige /proc-Einträge und geschützte Cron-Dateien übersprungen, und für jede wird eine Warnung protokolliert.

Schnellstart

Nur Erkennung — interaktive TUI:```bash sudo ubuntils scan

Erkennung mit CLI-Behebungsvorschau (Probelauf — keine Änderungen vorgenommen):```bash sudo ubuntils scan --remediate

Druckversion:```bash ubuntils version

Analysiere ein zuvor gesammeltes Bundle (keine Root-Rechte erforderlich):```bash ubuntils analyze /path/to/bundle.tar.gz --json

Siehe Offline-Analyse: Sammeln und Analysieren für das Bundle-Format und – wichtig – was die Offline-Analyse im Vergleich zu einem Live-scan nicht erkennen kann.

Flags und Konfiguration```

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

| --no-color | Deaktiviert farbige Ausgabe | | --debug | Aktiviert Debug-Ausgabe | | --verbose | Aktiviert ausführliche Ausgabe | | --version | Zeigt die Version an und beendet das Programm | | --help | Zeigt die Hilfe an und beendet das Programm |```bash sudo ubuntils scan --json --config allowlist.yaml

| -s | --server | Server URL to connect to (default: http://localhost:3000) | | -t | --token | Authentication token for the server | | -v | --verbose | Enable verbose logging | | -q | --quiet | Suppress non-essential output | | -o | --output | Output file path for results | | -f | --format | Output format: json, yaml, table (default: table) | | -c | --config | Path to configuration file | | -n | --no-color | Disable colored output | | -h | --help | Show help message and exit | | -V | --version | Show version information and exit |

Examples

Configuration File

The tool supports a configuration file in YAML format. By default, it looks for ~/.mytool/config.yaml.

Environment Variables

Exit Codes

Troubleshooting

Connection refused

If you see a "connection refused" error, ensure the server is running and accessible:

Authentication failed

Verify your token is correct and has not expired. You can regenerate a token from the web interface under Settings → API Tokens.

Timeout errors

Increase the timeout value using the --timeout flag or the MYTOOL_TIMEOUT environment variable:

Contributing

We welcome contributions from the community. Please read our Contributing Guide before submitting a pull request.

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

License

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

Acknowledgments

• Thanks to all contributors who have helped shape this project
• Inspired by similar tools in the open-source community
• Built with Go and Cobra```bash sudo ubuntils scan --json --baseline baseline.yaml

Ihre Frage bezieht sich auf die Übersetzung von Kitploit-Tool-Inhalten. Bitte senden Sie den tatsächlichen Markdown-Text, den Sie übersetzen möchten (Chunk 33 von 90), und ich werde ihn gemäß den angegebenen Regeln ins Deutsche übersetzen.```bash sudo ubuntils scan --json --rules custom_rules.yaml

Offline-Analyse: Sammeln und Analysieren

ubuntils scan führt Sammlung, Erkennung und Timeline gemeinsam gegen den laufenden Host aus. collect und analyze teilen diese Pipeline in zwei Schritte auf: collect erfasst ein manipulationssicheres Bundle von einem Host (es werden keine Erkennungsläufe durchgeführt), und analyze führt dieselbe Erkennungs-/Timeline-Pipeline, die von scan verwendet wird, gegen ein Bundle oder gegen ein gemountetes Image über --root aus, ohne Root-Rechte zu benötigen und ohne den ursprünglichen Host erneut zu berühren. Dies ist für Fälle gedacht, in denen Sie Artefakte einmal erfassen und später, an einem anderen Ort oder wiederholt analysieren möchten – oder in denen Sie ein Datenträgerabbild statt eines laufenden Systems untersuchen.

`ubuntils collect````bash

sudo ubuntils collect --output /path/to/bundle.tar.gz

Nimmt entweder einen Bundle-Pfad als positionales Argument oder --root PATH, das auf ein gemountetes Image / einen extrahierten Dateisystembaum zeigt — nicht beides. Führt dieselbe Erkennungs-Engine, benutzerdefinierten Regeln, Allowlist und Baseline-Logik aus, die von scan verwendet werden. Erfordert keine Root-Rechte. Das Bundle wird in ein privates temporäres Verzeichnis extrahiert, das gelöscht wird, sobald die Analyse abgeschlossen ist (es kann /etc/shadow enthalten).

Die Abdeckung unterscheidet sich zwischen den beiden Offline-Modi, da ein Bundle einen wiedergegebenen erfassten Zustand vom collect-Zeitpunkt trägt, während --root nur das hat, was sich auf dem gemounteten Dateisystem befindet:

• analyze BUNDLE gibt die echte ss/systemctl list-timers/journalctl-Befehlsausgabe wieder, die zum collect-Zeitpunkt erfasst wurde, sodass NetworkCollector und SystemdCollector echte Befunde aus diesem Snapshot liefern — sie werden nicht übersprungen. Die Timeline wird aus dem syslog/messages/audit.log/journalctl aufgebaut, das das Bundle erfasst hat, sodass sie vollständig befüllt ist und Befunde echte related_events-Korrelation erhalten.
• analyze --root PATH zeigt auf ein totes, gemountetes Image ohne Live-Prozess- oder Kernel-Zustand zum Abfragen, sodass die Befehlsausführung vollständig deaktiviert ist: NetworkCollector und SystemdCollector werden übersprungen und in scan_metadata.command_collectors_skipped vermerkt. Die Timeline wird weiterhin aufgebaut, aber aus den statischen Logdateien, die auf dem Image vorhanden sind (/var/log/syslog, /var/log/messages, /var/log/audit/audit.log) — journald-Replay ist hier nicht verfügbar, da kein Live-journalctl vorhanden ist, um ein totes Image abzufragen.

Siehe Offline-Analyse: collect und analyze für die vollständige Liste der Lücken in der Offline-Erkennungsabdeckung.

Bundle-Format

Ein Bundle ist ein gzipped Tarball mit allem unter einem bundle/-Präfix:``` 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

✓ markiert Erfolg, ✗ markiert Fehler, der Spinner markiert den aktiven Collector und leere Zeilen sind ausstehend. Sobald alle Collectors abgeschlossen sind und Erkennung + Timeline fertig sind, wechselt die TUI automatisch zum Ergebnisbildschirm.

Ergebnisbildschirm

Der Ergebnisbildschirm hat vier Tabs, die mit den Zifferntasten navigiert werden:

Drücken Sie q oder Ctrl+C zum Beenden.

Tab „Zusammenfassung" (Taste 1)

Zeigt Scan-Metadaten und die Top-Befunde auf einem einzigen Bildschirm:``` 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

In-TUI-Behebung

Für Befunde, für die eine automatisierte Behebung verfügbar ist, drücken Sie R, während der Befund ausgewählt ist. Ein Bestätigungsdialog erscheint:``` ┌─────────────────────────────────────────────────┐ │ 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 │ └─────────────────────────────────────────────────┘

Bei einem Fehler zeigt der Detailbereich den Fehler an. Die Sicherung wird immer erstellt, bevor eine Änderung versucht wird.

Drücken Sie Esc, um den Detailbereich einzuklappen.

Zeitleisten-Tab (Taste 3)

Eine scrollbare chronologische Liste korrelierter Protokollereignisse. Jede Zeile zeigt Zeitstempel, Quelle und Beschreibung. Ereignisse werden aus syslog, journald und auditd abgerufen und dedupliziert.

Statistik-Tab (Taste 4)

Eine Übersichtsansicht des Scans: erkannte Ubuntu-Version, Architektur, Scan-Dauer, Anzahl der Collector und Fehler sowie Anzahl der Befunde pro Schweregrad zusammen mit der Gesamtzahl der Zeitleisten-Ereignisse.

Was er erkennt

Warum jede Regel existiert

CRON_ROOT_EXEC — Benutzer-Crontabs laufen als Eigentümer des Crontabs. Ein Eintrag, der sudo oder einen root-eigenen Interpreter aufruft, bedeutet, dass der Benutzer dafür gesorgt hat, dass Code planmäßig mit root-Privilegien ausgeführt wird, ohne dauerhaften sudo-Zugriff zu benötigen. Dies übersteht Passwortänderungen.

Beispielfund:``` [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

LD_PRELOAD_INJECT — LD_PRELOAD veranlasst den dynamischen Linker, eine angegebene Shared Library vor allen anderen zu laden, was die beliebige Funktionsinterzeption in jeder dynamisch gelinkten Binärdatei ermöglicht. Ein Wert, der außerhalb der Standard-Bibliothekspfade zeigt, ist ein nahezu sicherer Indikator für einen Userspace-Rootkit; jede Bibliothek in einer durch Leerzeichen oder Doppelpunkte getrennten Liste wird überprüft. /etc/ld.so.preload injiziert in jeden Prozess und ist auf einem Standard-Ubuntu leer, daher wird jeder Eintrag dort gemeldet — selbst einer, der innerhalb von /lib platziert wurde, ein häufiger Rootkit-Trick. Die Behebung entfernt /etc/ld.so.preload-Einträge, anstatt sie auszukommentieren, da der Loader in dieser Datei keine Kommentarsyntax kennt.

Beispielfund:``` [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

SSH_UNAUTHORIZED_KEY — Ein neu hinzugefügter SSH-Schlüssel gewährt persistenten Fernzugriff unabhängig von Passwörtern. Das 7-Tage-Fenster erfasst kürzlich erfolgte Hinzufügungen und vermeidet gleichzeitig Rauschen durch die Ersteinrichtung auf älteren Systemen. Hinweis: Die Regel verwendet die Datei-mtime, die den letzten Schreibzugriff auf die authorized_keys-Datei widerspiegelt, nicht den Einfügezeitpunkt jedes einzelnen Schlüssels.

Beispielbefund:``` [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

PROCESS_MASQUERADE — Das Benennen einer bösartigen Binärdatei nach einem bekannten Systemprozess (sshd, python3, bash) ist eine grundlegende Technik, um die Erkennung in der ps-Ausgabe zu vermeiden. Diese Regel gleicht den Prozessnamen aus /proc/<pid>/status mit dem aufgelösten exe-Pfad aus /proc/<pid>/exe ab. Zu den Standardpfaden gehören /usr/local/{bin,sbin}, /usr/lib, /usr/libexec und /snap, sodass systemd (/usr/lib/systemd/systemd) und Snap-Pakete nicht anschlagen. Nur Kennzeichnung — das Beenden eines Prozesses erfordert menschliches Urteilsvermögen.

Beispielfund:``` [MEDIUM] PROCESS_MASQUERADE Title: Process masquerading as system binary Artifact: /proc/1337/exe Raw value: name=sshd, exe=/tmp/.sshd Remediation: not available

USER_EMPTY_PASSWORD — Ein Konto, dessen Passwortfeld in /etc/shadow leer ist, hat überhaupt kein Passwort, und Ubuntus Standard-PAM-Stack (pam_unix ... nullok) lässt es ohne eines anmelden. Bei einem Konto mit einer Login-Shell ist das eine offene Tür. Nur Flag — sperren Sie es mit passwd -l, während Sie untersuchen.

Beispielfund:``` [HIGH] USER_EMPTY_PASSWORD Title: Login account with no password Artifact: /etc/shadow Raw value: eve:: Remediation: not available

SHELL_RC_MODIFICATION — Shell-Init-Dateien sind ein zuverlässiger Persistenzvektor, da sie bei jeder Benutzeranmeldung ausgeführt werden. Diese Regel zeigt kürzliche Änderungen zur manuellen Überprüfung an. Nur-Flag — der Inhalt von Shell-RC-Dateien muss gelesen werden, bevor darauf reagiert wird.

Beispielbefund:``` [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

IMMUTABLE_FLAG_SET — Angreifer setzen häufig das Immutable-Flag (i) oder das Append-Only-Flag (a) auf Dateien, um Änderungen oder Löschungen zu verhindern, selbst durch root, unter anderem um Manipulationen vor weiteren Bearbeitungen/Log-Rotation zu verbergen. Das Setzen dieser Flags auf sensible Systemdateien wie /etc/passwd, /etc/sudoers, /etc/pam.d/* oder die auth/syslog/wtmp/btmp-Logdateien ist ein starker Hinweis auf eine Angreifer-Härtung. Diese Regel erkennt Immutable- und Append-Only-Flags über lsattr gegen diese feste Liste sensibler Pfade. Nur-Flag — Flag-Änderungen erfordern eine menschliche Überprüfung.

Beispielfund:``` [MEDIUM] IMMUTABLE_FLAG_SET Title: Sensitive file has an unexpected chattr flag Artifact: /etc/ld.so.preload Raw value: ----i--------e--- Remediation: not available

KERNEL_MODULE_SUSPICIOUS — Kernel-Module laufen im Ring 0 mit uneingeschränktem Zugriff. Angreifer laden häufig benutzerdefinierte Kernel-Module für Rootkits, Packet Sniffing oder Prozessverbergung. Diese Regel vergleicht aktuell geladene Module mit einer kleinen Allowlist erwarteter integrierter Module (die auf den meisten Systemen üblich sind). Sie hat den Schweregrad LOW, weil diese Allowlist bewusst eng gefasst ist. Hinweis: Hardware-lastige Hosts mit GPU-Treibern, WLAN-Karten oder proprietären Treibern erzeugen False Positives. Responder sollten die erwarteten Module ihres Hosts über --config hinzufügen und dabei nach Modulnamen allowlisten (der als artifact_path verwendet wird). Nur-Flag — die Untersuchung von Kernel-Modulen erfordert Forensik-Tools und menschliche Expertise.

Beispielfund:``` [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

JSON-Ausgabe

--json schreibt ein einzelnes JSON-Objekt nach stdout. Sonst wird nichts ausgegeben.```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)" }

Schutzmaßnahmen

Jede Behebung folgt demselben Muster, unabhängig davon, wie sie ausgelöst wird:

1. Prüfen, ob der Artefaktpfad ein Symlink ist — falls ja, ablehnen (verhindert, dass root durch angreiferkontrollierte Symlinks schreibt)
2. Ein zeitgestempeltes Backup unter /var/backups/ubuntils/YYYYMMDD_HHMMSS/ mit Modus 0700 erstellen
3. Aktuellen Zustand validieren (die exakte Zeile muss noch vorhanden sein)
4. Die minimal mögliche Änderung anwenden — Cron-Einträge und Schlüssel Zeile für Zeile entfernt; LD_PRELOAD-Zeilen in Shell-Init-Dateien auskommentiert; Einträge in /etc/ld.so.preload entfernt (der Loader hat dort keine Kommentarsyntax, ein auskommentierter Eintrag würde also trotzdem geladen). Bei sudoers wird der bearbeitete Inhalt mit visudo -cf an einer temporären Kopie geprüft, bevor die echte Datei angefasst wird
5. Atomar schreiben — neuer Inhalt geht in eine temporäre Datei neben dem Original (gleicher Modus und Eigentümer), wird fsync'd, dann über die Originaldatei umbenannt, sodass ein Absturz mitten im Schreiben keine abgeschnittene /etc/sudoers hinterlassen kann
6. Verifizieren, dass die exakte Zeile verschwunden ist

Wenn ein Schritt fehlschlägt, stoppt die Behebung sofort, das System bleibt unverändert, und der vollständige Fehler wird mit Backup-Pfad und Rollback-Befehl gemeldet. Sudo-Zugriff ist auf zwei Arten geschützt: %group-NOPASSWD-Regeln (wie %sudo) sind nur Flag-basiert und werden nie automatisch entfernt, und der sudoers-Remediator weigert sich, die letzte Regel aus der Haupt-sudoers-Datei zu entfernen.

Wazuh-Integration

ubuntils ist für eine Single-Host-Triage zu einem bestimmten Zeitpunkt gebaut — du führst es aus, wenn du bereits vermutest, dass etwas nicht stimmt, und es telefoniert nie nach Hause oder beobachtet weiter, nachdem der Scan beendet ist. Das ist Absicht, bedeutet aber auch, dass ein Befund von ubuntils nur in diesem einen Bericht lebt, es sei denn, etwas trägt ihn weiter. Die meisten Teams, die Ubuntu in irgendeinem Maßstab betreiben, haben bereits ein SIEM, das die kontinuierliche Seite der Erkennung übernimmt. Statt ubuntils zu einem eigenen langlaufenden Monitoring-Agenten zu machen, übergibt es seine Befunde an das, was du wahrscheinlich bereits betreibst: Wazuh.

Wenn ein Wazuh-Agent auf dem Host vorhanden ist (/var/ossec/bin/wazuh-agentd oder /var/ossec/etc/ossec.conf existiert), hängt ubuntils scan (sofern nicht mit --no-wazuh ausgeführt) jeden Befund als eine JSON-Zeile an /var/log/ubuntils/wazuh-alerts.json an, damit der Agent ihn aufnimmt — dies ist ein reiner Forwarder, kein Wazuh-Modul: kein Netzwerkaufruf, kein API-Schlüssel, nichts außer denselben lokalen Artefakt-Schreibvorgängen, die ubuntils ohnehin macht — wobei der Agent diese Zeilen natürlich außerhalb des Hosts an seinen Manager liefert; das ist der Sinn. Es wird automatisch erkannt, ohne dass ein Flag erforderlich ist (verwende --no-wazuh, um einen Lauf abzumelden), sodass ein skriptgesteuerter oder geplanter ubuntils scan auf einer Flotte von agentenregistrierten Hosts sofort das SIEM speist, ohne zusätzliche Verkabelung. Dies geschieht nie während des Offline-ubuntils analyze (Bundle oder --root), da diese Befunde einen anderen Host beschreiben als den, der den lokalen Wazuh-Agenten ausführt — das Weiterleiten der Befunde eines Bundles an den eigenen Agenten des Analysten würde sie der falschen Maschine zuordnen.

Die Absicht ist, ubuntils in eine bestehende Alerting-/Eskalations-Pipeline einzufügen, statt einen Responder zu bitten, ein zweites Tool zu hüten: Sobald die untenstehenden Beispielregeln geladen sind, erscheint ein ubuntils-Befund mit hohem Schweregrad (ein neues UID-0-Konto, ein LD_PRELOAD-Rootkit, eine PAM-Backdoor) als normaler Wazuh-Alert, erbt das gesamte Benachrichtigungs-Routing, das der Manager bereits konfiguriert hat, und steht neben jedem anderen Signal in derselben Timeline statt in einer eigenständigen JSON-Datei, an deren Überprüfung sich jemand erinnern muss.

Damit Wazuh diese Befunde parst und alarmiert, kopiere die Beispielregeln aus examples/wazuh/ auf deinen Wazuh-Manager und füge den <localfile>-Block aus examples/wazuh/ossec_localfile_snippet.xml zur /var/ossec/etc/ossec.conf des Agenten hinzu. Es ist keine Installation eines benutzerdefinierten Decoders nötig: Die localfile ist mit log_format json konfiguriert, sodass Wazuhs eingebauter JSON-Decoder jede Zeile parst und jeden Top-Level-JSON-Schlüssel k auf data.k abbildet, worauf local_rules.xml direkt matcht.

1. examples/wazuh/local_rules.xml → /var/ossec/etc/rules/ des Managers
2. <localfile>-Block aus examples/wazuh/ossec_localfile_snippet.xml → /var/ossec/etc/ossec.conf des Agenten
3. Beide neu starten: systemctl restart wazuh-manager (Manager), systemctl restart wazuh-agent (Agent-Host)

Dies sind nur Beispielvorlagen, die als Ausgangspunkt dienen — sie wurden nicht gegen einen Live-Wazuh-Manager getestet und sollten in einer Nicht-Produktionsumgebung verifiziert werden, bevor man sich auf sie verlässt.

JSON-Schema pro Zeile:

Collectors

Collector-Abhängigkeiten

PackageCollector benötigt drei Standard-Ubuntu-Tools auf dem Live-Host (dpkg, lsattr, find — alle auf Standard-Ubuntu-Installationen vorhanden). Wenn ein Befehl nicht verfügbar ist, erzeugt PackageCollector für diesen Teil auf saubere Weise leere Daten, statt abzustürzen. Die Offline-Analyse (analyze BUNDLE) spielt die aufgezeichnete Befehlsausgabe vom collect-Zeitpunkt erneut ab, sodass die Befehlsverfügbarkeit auf dem Host des Analysators nicht erforderlich ist.

Der setuid/setgid-find-Scan übergibt -xdev, um begrenzt zu bleiben — er steigt nicht in separat gemountete Dateisysteme hinab (ein eigenständiger Mount unter /opt, ein NFS-gemountetes /home usw.). Dies ist ein bewusster Kompromiss zwischen Laufzeit und Abdeckung: Ohne -xdev könnte der Scan beim Scannen von Netzwerk-Mounts oder virtuellen Dateisystemen hängen bleiben. Wenn deine Umgebung diese Pfade auf separaten Dateisystemen mountet, sei dir bewusst, dass sie nicht gescannt werden.

dpkg --verify und der setuid/setgid-find-Scan verwenden großzügige, nicht standardmäßige Timeouts (10 Minuten bzw. 5 Minuten, siehe ubuntils/collectors/packages.py), da beide auf einem echten Host mit großer Paketdatenbank oder großem Dateisystembaum legitim weit über den Bibliotheksstandard von 30 Sekunden hinaus laufen können; ubuntils collect verwendet dieselben Timeouts, wenn diese Befehle in ein Bundle aufgenommen werden.

Kompatibilität

Die Ausführung ohne Root erzeugt einen Teilscan mit Warnungen. Kritische Pfade wie /etc/shadow, geschützte Crontab-Verzeichnisse und einige /proc-Einträge werden übersprungen.

Roadmap

v1.0.0

• Alle 8 Collectors
• Alle 8 Erkennungsregeln
• Timeline-Builder (syslog, journald, auditd)
• Live-Scan-Fortschrittsbildschirm mit ✓/✗ pro Collector
• Interaktive Vier-Tab-TUI (Summary / Findings / Timeline / Stats)
• In-TUI-Behebung mit Bestätigungsmodal und Hintergrund-Worker
• JSON-Ausgabemodus
• CLI-Behebung für 5 Regeln mit Backup, Rollback und Symlink-Schutz
• Ubuntu 20.04/22.04/24.04-Unterstützung
• 240 Tests bei 90 % Abdeckung

v1.1.0

• False-Positive-Allowlisting nach Regel-ID oder Pfad (--config)
• --output FILE zum direkten Schreiben von Berichten
• --since-Timeline-Fensterung
• Manipulationssichere Berichte (report_sha256, Hostname, Zeitstempel)
• USER_UID_ZERO-Erkennungsregel

v1.5.0

• Benutzerdefinierte Pattern-Match-Erkennungsregeln via YAML (--rules)
• PROCESS_SUSPICIOUS_CONNECTION — Prozess↔Netzwerk-Korrelation per PID
• Automatische Befund↔Timeline-Korrelation (related_events)
• Geführte Behebung für die drei Regeln, die Urteilsvermögen erfordern
• 282 Tests bei 92 % Abdeckung

VirusTotal-Hash-Abfragen und MISP-IOC-Export wurden aus diesem Release gestrichen. VirusTotal antwortet nur für bekannte Hashes — der Fall, den rkhunter bereits abdeckt, und das Gegenteil der Lücke bei neuartigen Techniken, auf die ubuntils abzielt — und beide Funktionen hätten einen Netzwerkaufruf in ein Tool eingebaut, dessen Wert darauf beruht, keinen zu machen. ubuntils selbst macht weiterhin keine Netzwerkaufrufe (siehe die Wazuh-Integration für den einen abmeldbaren Weg, wie Befunde den Host über einen lokalen Agenten verlassen können).

v2.0.0 — Offline-Collect/Analyze-Split

• ubuntils collect — erfasst ein manipulationssicheres Bundle (manifest.json + gehashte Dateien/Befehle) von einem Live-Host, ohne Erkennung
• ubuntils analyze (BUNDLE | --root PATH) — führt dieselbe Erkennungs-/Timeline-Pipeline wie scan gegen ein Bundle oder ein gemountetes Image aus, ohne Root erforderlich
• bundle_integrity (live/ok/mismatch) in scan_metadata sichtbar gemacht
• Dokumentierte Lücken in der Erkennungsabdeckung im Offline-Modus (PROCESS_MASQUERADE, PROCESS_SUSPICIOUS_CONNECTION und reduzierte Abdeckung für cron/sudoers/SSH-Glob-Pfade und systemd-Timer-ExecStart)
• Vertrauenswürdige Erkennung: Confidence-Scoring (confidence/confidence_band/signals), --baseline-Unterdrückung, Ersetzung reiner mtime-Heuristiken in SSH_UNAUTHORIZED_KEY/SHELL_RC_MODIFICATION durch ctime- und Inhalts-Signale sowie eine echte Offline-Timeline für sowohl analyze BUNDLE als auch analyze --root
• Coverage-Pack: PACKAGE_TAMPERED, IMMUTABLE_FLAG_SET, PAM_BACKDOOR, KERNEL_MODULE_SUSPICIOUS, SETUID_INVENTORY (via PackageCollector, PamCollector, KernelCollector; alle konstruktionsbedingt nur Flag-basiert)
• 400 Tests bei 93,79 % Abdeckung

v2.1.0 — SIEM-Forwarding

• Live-ubuntils scan-Befunde werden als JSONL an einen lokalen Wazuh-Agenten weitergeleitet, automatisch erkannt (kein Flag erforderlich)
• Beispiel-Wazuh-Decoder/-Regeln und ossec.conf-<localfile>-Snippet (examples/wazuh/)
• Forwarding absichtlich nur auf Live-scan beschränkt — wird nie während Offline-analyze ausgelöst, da ein Bundle oder Image einen anderen Host beschreibt als den, der den Agenten ausführt
• --no-wazuh, um einen Scan vom Forwarding abzumelden

v2.1.0 — Härtung (Audit der gesamten Codebasis)

• Sicherheit: sudo-Re-Exec leitet den PATH des Aufrufers nicht mehr weiter, und Befehle werden auf einem festen sicheren Pfad aufgelöst; sudoers-Bearbeitungen werden mit visudo geprüft, bevor die Datei angefasst wird; atomare Behebungsschreibvorgänge; symlink-sichere Berichts-/Bundle-Ausgabe; extrahierte Bundles werden nach analyze gelöscht
• Erkennungsabdeckung: /etc/ld.so.preload geparst, @reboot/@daily-Cron-Einträge und /etc/cron.{hourly,daily,weekly,monthly}-Skripte, systemd-.service-Units und nicht root-eigene ExecStart-Binaries, %group-sudoers-Regeln und #include/@includedir, jedes Element einer LD_PRELOAD-Liste
• Neue USER_EMPTY_PASSWORD-Regel (Login-Konto ohne Passwort)
• Weniger False Positives: separator-begrenzte Pfadprüfungen, setuid vs. setgid unterschieden, snap-//usr/lib-Daemons als Standard behandelt, KERNEL_MODULE_SUSPICIOUS auf LOW herabgestuft, ein NSS-Befund pro Modul
• Ehrliche Berichte: fehlgeschlagene Regeln und degradierte Collectors in scan_metadata und der TUI erfasst; ein Timeline-Fehler verwirft keine Befunde mehr; manipulierte Bundles warnen und beenden mit Exit-Code 3; syslog-Jahr/Zeitzone korrekt behandelt
• Sicherere Behebung: --min-confidence-Gate (Standard 40), Ergebnisse nach scan --remediate in der TUI angezeigt
• 444 Tests bei 94,29 % Abdeckung

v3.0.0 / v4.0.0 (explorativ)

• Web-Dashboard für Multi-Host-Triage
• macOS-Unterstützung

Mitwirken

Die derzeit nützlichsten Beiträge sind neue Erkennungsregeln (hinzugefügt als eigenständige Funktionen in detectors/rules.py mit einem passenden Test), zusätzliche Collectors für noch nicht abgedeckte Artefakttypen, Behebungsmodule für SUSPICIOUS_SYSTEMD_TIMER und SHELL_RC_MODIFICATION (beide derzeit konstruktionsbedingt nur Flag-basiert, aber sichere automatische Behebungspfade könnten existieren), Testfälle für Randfälle bei bestimmten Ubuntu-Konfigurationen und Dokumentationsverbesserungen.

Öffne ein Issue, bevor du einen großen Beitrag beginnst, um doppelte Arbeit zu vermeiden.

Lizenz

MIT

Autor

Erstellt von Asmit — BTech Computer Science, PES University, Bengaluru. Das Tool entstand aus der Frustration darüber, wie lange manuelle Ubuntu-Triage dauert im Vergleich zu dem, was ein gut abgegrenztes Skript automatisieren kann.