ubuntils

CLI/TUI Python pour le triage forensique des systèmes Ubuntu — détecte et remédie aux mécanismes de persistance avec collecte d'artefacts, corrélation temporelle et intégration Wazuh.

Lorsque vous soupçonnez qu'un système Linux est compromis, les 30 à 40 premières minutes sont généralement consacrées à exécuter les mêmes dix commandes en séquence : vérifier les processus en cours, rechercher des tâches cron suspectes, faire un grep sur LD_PRELOAD, analyser authorized_keys à la recherche de nouvelles entrées, auditer sudoers. Chaque étape est manuelle, implique des changements de contexte et est source d'erreurs sous pression. Oubliez une seule source — par exemple /etc/sudoers.d/ au lieu de simplement /etc/sudoers, ou les crontabs utilisateur en plus de /etc/cron.d/ — et vous obtenez une image incomplète.

Les options existantes ne résolvent pas ce problème proprement. lynis est un auditeur de durcissement, pas un outil de triage — il signale les faiblesses de configuration sur un système sain et génère du bruit sur un système compromis. chkrootkit et rkhunter vérifient les signatures de rootkits connus mais sont aveugles aux techniques de persistance inédites comme les timers systemd détournés ou les entrées cron d'apparence légitime. Les requêtes SIEM génériques nécessitent une infrastructure de journalisation qui peut ne pas exister sur le système que vous examinez. Et les suites forensiques comme Volatility ciblent les images mémoire, pas un shell actif sur un hôte en fonctionnement.

Le manque, c'est un outil qui s'exécute sur le système en production immédiatement, couvre les vecteurs de persistance les plus courants, corrèle l'activité entre les sources de journaux dans une chronologie, et vous indique exactement ce qu'il faut examiner — sans nécessiter d'agent externe, de base de données ni de connexion internet.

Ce que fait ubuntils

ubuntils s'exécute en quatre étapes séquentielles :

1. Collecte — Onze collecteurs rassemblent des artefacts forensiques en parallèle depuis /proc, les tables cron, les unités systemd, les clés SSH, les fichiers sudoers, les définitions d'environnement, l'intégrité des paquets (dpkg --verify), la configuration PAM/NSS et les modules du noyau chargés. Prend environ 2,5 secondes sur un système typique.
2. Détection — Un moteur de détection exécute les seize règles intégrées — plus toute règle personnalisée chargée avec --rules — sur les artefacts collectés, produisant une liste de résultats classés et notés par niveau de confiance en environ une seconde.
3. Chronologie — Un constructeur de chronologie lit syslog, journald et auditd en parallèle et corrèle les événements chronologiquement, ajoutant environ 0,3 seconde. Chaque résultat est ensuite auto-corrélé avec la chronologie, de sorte qu'il porte les événements proches qui s'y rapportent.
4. Sortie — Les résultats apparaissent soit dans une TUI interactive à quatre onglets (par défaut), soit en JSON structuré sur stdout (--json).

ubuntils lui-même n'effectue aucun appel réseau, et chaque fonctionnalité — règles personnalisées et corrélation incluses — s'exécute sur des artefacts collectés localement. La seule façon dont les résultats peuvent quitter l'hôte est l'intégration Wazuh : si un agent Wazuh est installé, un scan en direct écrit ses résultats dans un fichier local que l'agent transmet ensuite à son manager. Passez --no-wazuh pour désactiver cela pour une exécution.

ubuntils scan n'est pas modifié par tout ce qui suit — il reste 100 % en direct, mono-hôte, et chaque option existante fonctionne à l'identique. Deux commandes supplémentaires, collect et analyze, divisent le même pipeline de détection/chronologie en un flux de travail acquire-then-analyze adapté au mode hors ligne pour les cas où vous ne pouvez pas (ou ne voulez pas) exécuter la détection directement sur l'hôte examiné — voir Analyse hors ligne : collect et analyze ci-dessous, y compris ses réserves sur la couverture de détection.

Installation

Ubuntu 22.04+ et tout système avec PEP 668 (recommandé) :

Ubuntu 22.04+ bloque pip install à l'échelle du système. Utilisez pipx — il gère l'environnement de manière transparente pour que vous n'ayez jamais à y penser :```bash sudo apt install pipx -y cd ubuntils pipx install -e . ubuntils scan

ubuntils nécessite les droits root pour un accès complet aux artefacts. Si vous exécutez ubuntils scan en tant qu'utilisateur non-root, il se réinvoquera automatiquement avec sudo en utilisant le même interpréteur Python (par chemin absolu), afin que l'environnement correct soit utilisé sans transmettre votre PATH au processus root. Chaque commande externe (ss, dpkg, systemctl, …) est résolue sur un chemin de recherche fixe, appartenant à root, jamais votre PATH. Une exécution sans root ignorera /etc/shadow, certaines entrées /proc et les fichiers cron protégés, et enregistrera des avertissements pour chacun.

Démarrage rapide

Détection uniquement — TUI interactive :```bash sudo ubuntils scan

Détection avec aperçu de remédiation CLI (exécution à blanc — aucune modification appliquée) :```bash sudo ubuntils scan --remediate

Version imprimable :```bash ubuntils version

Analyser un bundle précédemment collecté (aucun accès root requis) :```bash ubuntils analyze /path/to/bundle.tar.gz --json

Voir Analyse hors ligne : collecter et analyser pour le format du bundle et — surtout — ce que l'analyse hors ligne ne peut pas détecter par rapport à un scan en direct.

Flags et configuration```

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

I'm ready to translate the Kitploit tool content from English to French. Please provide chunk 25 of 90.```bash sudo ubuntils scan --json --config allowlist.yaml

I don't have the source content to translate. You mentioned "INPUT:" but no actual Markdown text was included after it.

Please paste the chunk 29/90 content you'd like translated from English to French, and I'll return only the translated Markdown with all structure, code, paths, URLs, and identifiers preserved exactly as-is.```bash sudo ubuntils scan --json --baseline baseline.yaml

Installation

Prérequis

• Python 3.8+
• pip
• Git

Étapes

1. Cloner le dépôt

   root@kitploit:~

   git clone https://github.com/yourusername/kitploit-tool.git
   cd kitploit-tool
   

2. Créer un environnement virtuel

   root@kitploit:~

   python3 -m venv venv
   source venv/bin/activate  # Sur Windows : venv\Scripts\activate
   

3. Installer les dépendances

   root@kitploit:~

   pip install -r requirements.txt
   

4. Configurer les variables d'environnement

   root@kitploit:~

   cp .env.example .env
   # Modifiez .env avec vos paramètres
   

5. Lancer l'outil

   root@kitploit:~

   python main.py --help
   

Utilisation

Commandes de base

Options avancées

Exemples

Scanner un réseau :

Exporter les résultats :

Configuration

Le fichier de configuration se trouve dans config/settings.yaml :

Dépannage

Problèmes courants

Erreur : Module introuvable

Erreur de permission

Conflit de port Modifiez le port dans config/settings.yaml ou utilisez l'option --port.```bash sudo ubuntils scan --json --rules custom_rules.yaml

Analyse hors ligne : collecter et analyser

ubuntils scan exécute la collecte, la détection et la chronologie ensemble sur l'hôte actif. collect et analyze scindent ce pipeline en deux : collect acquiert un bundle inviolable depuis un hôte (aucune détection n'est exécutée), et analyze exécute le même pipeline de détection/chronologie utilisé par scan sur un bundle, ou sur une image montée via --root, sans nécessiter root et sans toucher à nouveau l'hôte d'origine. Cela concerne les cas où vous souhaitez acquérir des artefacts une fois et les analyser plus tard, ailleurs ou de manière répétée — ou lorsque vous triez une image disque plutôt qu'un système en cours d'exécution.

`ubuntils collect````bash

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

Prend soit un chemin de bundle comme argument positionnel, soit --root PATH pointant vers une image montée / une arborescence de système de fichiers extraite — pas les deux. Exécute le moteur de détection identique, les règles personnalisées, la liste d'autorisation et la logique de référence utilisés par scan. Ne nécessite pas root. Le bundle est extrait dans un répertoire temporaire privé qui est supprimé dès que l'analyse se termine (il peut contenir /etc/shadow).

La couverture diffère entre les deux modes hors ligne, car un bundle transporte un état capturé rejoué au moment de collect tandis que --root ne dispose que de ce qui se trouve sur le système de fichiers monté :

• analyze BUNDLE rejoue la sortie réelle des commandes ss/systemctl list-timers/journalctl capturée au moment de collect, de sorte que NetworkCollector et SystemdCollector produisent de véritables résultats à partir de cet instantané — ils ne sont pas ignorés. La chronologie est construite à partir des syslog/messages/audit.log/journalctl capturés par le bundle, elle est donc entièrement peuplée et les résultats obtiennent une véritable corrélation related_events.
• analyze --root PATH pointe vers une image montée, morte, sans état de processus ou de noyau actif à interroger, donc l'exécution de commandes est entièrement désactivée : NetworkCollector et SystemdCollector sont ignorés, enregistrés dans scan_metadata.command_collectors_skipped. La chronologie est toujours construite, mais à partir des fichiers de journal statiques présents sur l'image (/var/log/syslog, /var/log/messages, /var/log/audit/audit.log) — le rejeu journald n'est pas disponible ici puisqu'il n'y a pas de journalctl actif pour interroger une image morte.

Voir Analyse hors ligne : collect et analyze pour la liste complète des lacunes de couverture de détection hors ligne.

Format du bundle

Un bundle est une archive tar gzippée avec tout sous un préfixe bundle/ :``` bundle/ ├── manifest.json ├── files/ │ ├── etc/passwd │ ├── etc/shadow │ ├── var/log/syslog │ └── ... # every captured file, path-flattened under files/ └── commands/ ├── ss.txt ├── netstat.txt ├── systemctl_list_timers_json.txt ├── systemctl_list_timers_text.txt └── journalctl.txt

✓ indique un succès, ✗ indique un échec, le spinner indique le collecteur actif, et les lignes vides sont en attente. Une fois que tous les collecteurs ont terminé et que la détection + la chronologie sont complètes, le TUI bascule automatiquement vers l'écran des résultats.

Écran des résultats

L'écran des résultats comporte quatre onglets navigables par les touches numériques :

Appuyez sur q ou Ctrl+C pour quitter.

Onglet Résumé (touche 1)

Affiche les métadonnées du scan et les principales conclusions sur un seul écran :``` 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

Remédiation dans l'interface TUI

Pour les résultats disposant d'une remédiation automatisée, appuyez sur R lorsque le résultat est sélectionné. Une fenêtre de confirmation apparaît :``` ┌─────────────────────────────────────────────────┐ │ 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 │ └─────────────────────────────────────────────────┘

En cas d'échec, le volet de détail affiche l'erreur. La sauvegarde est toujours créée avant toute tentative de modification.

Appuyez sur Esc pour réduire le volet de détail.

Onglet Timeline (touche 3)

Une liste chronologique défilable des événements de journal corrélés. Chaque ligne affiche l'horodatage, la source et la description. Les événements sont extraits de syslog, journald et auditd puis dédupliqués.

Onglet Stats (touche 4)

Une vue récapitulative du scan : version d'Ubuntu détectée, architecture, durée du scan, nombre de collecteurs et échecs, et nombre de détections par sévérité ainsi que le total des événements de la timeline.

Ce qu'il détecte

Pourquoi chaque règle existe

CRON_ROOT_EXEC — Les crontabs utilisateur s'exécutent en tant que propriétaire du crontab. Une entrée invoquant sudo ou un interpréteur appartenant à root signifie que l'utilisateur a organisé l'exécution de code avec les privilèges root selon un planning, sans avoir besoin d'un accès sudo persistant. Cela survit aux changements de mot de passe.

Exemple de détection :``` [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 amène l'éditeur de liens dynamique à charger une bibliothèque partagée spécifiée avant toutes les autres, permettant l'interception arbitraire de fonctions dans tout binaire lié dynamiquement. Une valeur pointant en dehors des chemins de bibliothèques standard est un indicateur quasi certain de rootkit en espace utilisateur ; chaque bibliothèque d'une liste séparée par des espaces ou des deux-points est vérifiée. /etc/ld.so.preload s'injecte dans chaque processus et est vide sur une installation Ubuntu standard, donc toute entrée y figurant est signalée — même une entrée placée dans /lib, une astuce courante de rootkit. La remédiation supprime les entrées de /etc/ld.so.preload plutôt que de les commenter, car le chargeur n'a pas de syntaxe de commentaire dans ce fichier.

Exemple de détection :``` [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 — Une clé SSH nouvellement ajoutée accorde un accès distant persistant indépendant des mots de passe. La fenêtre de 7 jours détecte les ajouts récents tout en évitant le bruit lié au provisionnement initial sur les systèmes plus anciens. Remarque : la règle utilise le mtime du fichier, qui reflète la dernière écriture dans le fichier authorized_keys, et non l'horodatage d'insertion de chaque clé individuelle.

Exemple de résultat :``` [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 — Nommer un binaire malveillant d'après un processus système connu (sshd, python3, bash) est une technique de base pour éviter la détection dans la sortie de ps. Cette règle croise le nom du processus issu de /proc/<pid>/status avec le chemin exe résolu depuis /proc/<pid>/exe. Les emplacements standard incluent /usr/local/{bin,sbin}, /usr/lib, /usr/libexec et /snap, de sorte que systemd (/usr/lib/systemd/systemd) et les paquets snap ne la déclenchent pas. Signalement uniquement — tuer un processus requiert un jugement humain.

Exemple de détection :``` [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 — Un compte dont le champ mot de passe dans /etc/shadow est vide n'a aucun mot de passe, et la pile PAM par défaut d'Ubuntu (pam_unix ... nullok) lui permet de se connecter sans mot de passe. Sur un compte disposant d'un shell de connexion, c'est une porte ouverte. Signalement uniquement — verrouillez-le avec passwd -l pendant votre investigation.

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

SHELL_RC_MODIFICATION — Les fichiers d'initialisation du shell constituent un vecteur de persistance fiable car ils s'exécutent à chaque connexion de l'utilisateur. Cette règle fait remonter les modifications récentes pour examen humain. Signalement uniquement — le contenu des fichiers RC du shell doit être lu avant toute action.

Exemple de résultat :``` [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 — Les attaquants définissent souvent l'attribut immuable (i) ou l'attribut append-only (a) sur des fichiers afin d'empêcher leur modification ou leur suppression, même par root, y compris pour dissimuler une altération vis-à-vis d'éditions ultérieures ou de la rotation des journaux. Définir ces attributs sur des fichiers système sensibles comme /etc/passwd, /etc/sudoers, /etc/pam.d/*, ou les fichiers de journal auth/syslog/wtmp/btmp est un fort indicateur de durcissement par un attaquant. Cette règle détecte les attributs immuable et append-only via lsattr sur cette liste fixe de chemins sensibles. Signalement uniquement — les modifications d'attributs nécessitent une revue humaine.

Exemple de détection :``` [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 — Les modules du noyau s'exécutent en ring 0 avec un accès illimité. Les attaquants chargent fréquemment des modules noyau personnalisés pour des rootkits, l'analyse de paquets ou la dissimulation de processus. Cette règle compare les modules actuellement chargés à une petite liste d'autorisation de modules intégrés attendus (communs à la plupart des systèmes). Sa sévérité est LOW car cette liste d'autorisation est délibérément restreinte. Remarque : les hôtes fortement équipés en matériel avec des pilotes GPU, des cartes Wi-Fi ou des pilotes propriétaires généreront des faux positifs. Les intervenants doivent ajouter les modules attendus de leur hôte via --config, en autorisant par nom de module (utilisé comme artifact_path). Flag-only — l'investigation des modules noyau nécessite des outils forensiques et une expertise humaine.

Exemple de résultat :``` [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

Sortie JSON

--json écrit un seul objet JSON sur stdout. Rien d'autre n'est imprimé.```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)" }

Mesures de protection

Chaque remédiation suit le même schéma, quel que soit son déclencheur :

1. Détecter si le chemin de l'artefact est un lien symbolique — refuser dans ce cas (empêche l'écriture root à travers des liens symboliques contrôlés par un attaquant)
2. Créer une sauvegarde horodatée dans /var/backups/ubuntils/YYYYMMDD_HHMMSS/ avec le mode 0700
3. Valider l'état actuel (la ligne exacte doit toujours être présente)
4. Appliquer la modification minimale possible — les entrées cron et les clés sont supprimées ligne par ligne ; les lignes LD_PRELOAD dans les fichiers d'initialisation du shell sont commentées ; les entrées dans /etc/ld.so.preload sont supprimées (le loader n'a pas de syntaxe de commentaire à cet endroit, donc une entrée commentée serait quand même chargée). Pour sudoers, le contenu modifié est vérifié avec visudo -cf sur une copie temporaire avant que le fichier réel ne soit touché
5. Écrire de manière atomique — le nouveau contenu va dans un fichier temporaire à côté de l'original (même mode et propriétaire), est fsync'd, puis renommé par-dessus, afin qu'un crash en cours d'écriture ne puisse pas laisser un /etc/sudoers tronqué
6. Vérifier que la ligne exacte a disparu

Si une étape échoue, la remédiation s'arrête immédiatement, le système est laissé inchangé, et l'erreur complète est signalée avec le chemin de sauvegarde et la commande de rollback. L'accès sudo est protégé de deux manières : les règles NOPASSWD %group (comme %sudo) sont en lecture seule et ne sont jamais supprimées automatiquement, et le remédiateur sudoers refuse de supprimer la dernière règle du fichier sudoers principal.

Intégration Wazuh

ubuntils est conçu pour un triage mono-hôte et ponctuel — vous l'exécutez quand vous suspectez déjà qu'il y a un problème, et il ne communique jamais vers l'extérieur ni ne continue à surveiller après la fin du scan. C'est délibéré, mais cela signifie aussi qu'une découverte d'ubuntils ne vit que dans ce seul rapport, à moins que quelque chose ne la transmette. La plupart des équipes exploitant Ubuntu à quelque échelle que ce soit disposent déjà d'un SIEM assurant le volet continu de la détection, donc plutôt que d'intégrer ubuntils dans son propre agent de surveillance longue durée, il transmet ses découvertes à celui que vous exécutez probablement déjà : Wazuh.

Si un agent Wazuh est présent sur l'hôte (/var/ossec/bin/wazuh-agentd ou /var/ossec/etc/ossec.conf existe), ubuntils scan (sauf exécution avec --no-wazuh) ajoute chaque découverte sous forme d'une ligne JSON à /var/log/ubuntils/wazuh-alerts.json pour que l'agent la récupère — c'est un pur transmetteur, pas un module Wazuh : aucun appel réseau, aucune clé API, rien d'autre que les mêmes écritures d'artefacts locales qu'ubuntils effectue déjà — bien que l'agent expédiera bien sûr ces lignes hors de l'hôte vers son manager ; c'est le but. Il est auto-détecté sans flag requis (utilisez --no-wazuh pour exclure une exécution), donc un ubuntils scan scripté ou planifié sur un parc d'hôtes enrôlés auprès d'un agent commence à alimenter le SIEM immédiatement sans câblage supplémentaire. Cela ne se produit jamais pendant un ubuntils analyze hors ligne (bundle ou --root), car ces découvertes décrivent un hôte différent de celui exécutant l'agent Wazuh local — transmettre les découvertes d'un bundle à l'agent de l'analyste lui-même les attribuerait à la mauvaise machine.

L'intention est d'intégrer ubuntils dans un pipeline d'alerte/escalade existant plutôt que de demander à un intervenant de surveiller un second outil : une fois les règles d'exemple ci-dessous chargées, une découverte ubuntils de sévérité HIGH (un nouveau compte UID-0, un rootkit LD_PRELOAD, une backdoor PAM) apparaît comme une alerte Wazuh normale, hérite de tout routage de notification que le manager a déjà configuré, et se place aux côtés de tous les autres signaux dans la même chronologie au lieu d'un fichier JSON autonome que quelqu'un doit penser à consulter.

Pour que Wazuh analyse et alerte sur ces découvertes, copiez les règles d'exemple depuis examples/wazuh/ sur votre manager Wazuh, et ajoutez le bloc <localfile> depuis examples/wazuh/ossec_localfile_snippet.xml au fichier /var/ossec/etc/ossec.conf de l'agent. Aucune installation de décodeur personnalisé n'est nécessaire : le localfile est configuré avec log_format json, donc le décodeur JSON intégré de Wazuh analyse chaque ligne et mappe chaque clé JSON de premier niveau k vers data.k, que local_rules.xml fait correspondre directement.

1. examples/wazuh/local_rules.xml → /var/ossec/etc/rules/ du manager
2. Le bloc <localfile> de examples/wazuh/ossec_localfile_snippet.xml → /var/ossec/etc/ossec.conf de l'agent
3. Redémarrer les deux : systemctl restart wazuh-manager (manager), systemctl restart wazuh-agent (hôte de l'agent)

Ce ne sont que des modèles d'exemple, fournis comme point de départ — ils n'ont pas été testés contre un manager Wazuh en production et doivent être vérifiés dans un environnement non-production avant de s'y fier.

Schéma JSON par ligne :

Collecteurs

Dépendances des collecteurs

PackageCollector nécessite trois outils Ubuntu standard sur l'hôte actif (dpkg, lsattr, find — tous présents sur les installations Ubuntu standard). Si une commande est indisponible, PackageCollector produit gracieusement des données vides pour cette portion plutôt que de planter. L'analyse hors ligne (analyze BUNDLE) rejoue la sortie de commande capturée au moment de collect, donc la disponibilité des commandes sur l'hôte de l'analyseur n'est pas requise.

Le scan find setuid/setgid passe -xdev pour rester borné — il ne descend pas dans les systèmes de fichiers montés séparément (un montage distinct sous /opt, un /home monté en NFS, etc.). C'est un compromis délibéré entre temps d'exécution et couverture : sans -xdev, le scan pourrait se bloquer en scannant des montages réseau ou des systèmes de fichiers virtuels. Si votre environnement monte ces chemins sur des systèmes de fichiers séparés, sachez qu'ils ne seront pas scannés.

dpkg --verify et le scan find setuid/setgid utilisent des timeouts non-défaut généreux (10 minutes et 5 minutes respectivement, voir ubuntils/collectors/packages.py) car les deux peuvent légitimement dépasser largement la valeur par défaut de la bibliothèque de 30 secondes sur un hôte réel avec une grande base de données de paquets ou une grande arborescence de fichiers ; ubuntils collect utilise les mêmes timeouts lors de la capture de ces commandes dans un bundle.

Compatibilité

Une exécution sans root produit un scan partiel avec des avertissements. Les chemins critiques comme /etc/shadow, les répertoires crontab protégés et certaines entrées /proc seront ignorés.

Feuille de route

v1.0.0

• Les 8 collecteurs
• Les 8 règles de détection
• Générateur de chronologie (syslog, journald, auditd)
• Écran de progression du scan en direct avec ✓/✗ par collecteur
• TUI interactive à quatre onglets (Summary / Findings / Timeline / Stats)
• Remédiation dans la TUI avec modale de confirmation et worker en arrière-plan
• Mode de sortie JSON
• Remédiation CLI pour 5 règles avec sauvegarde, rollback et garde contre les liens symboliques
• Prise en charge d'Ubuntu 20.04/22.04/24.04
• 240 tests à 90 % de couverture

v1.1.0

• Liste blanche de faux positifs par ID de règle ou chemin (--config)
• --output FILE pour écrire les rapports directement
• Fenêtrage de chronologie --since
• Rapports inviolables (report_sha256, hostname, timestamp)
• Règle de détection USER_UID_ZERO

v1.5.0

• Règles de détection personnalisées par correspondance de motifs via YAML (--rules)
• PROCESS_SUSPICIOUS_CONNECTION — corrélation processus↔réseau par PID
• Corrélation automatique découverte↔chronologie (related_events)
• Remédiation guidée pour les trois règles nécessitant un jugement
• 282 tests à 92 % de couverture

Les recherches de hachages VirusTotal et l'export IOC MISP ont été abandonnés dans cette version. VirusTotal ne répond que pour les hachages connus — le cas que rkhunter couvre déjà, et l'opposé du vide de techniques nouvelles que ubuntils cible — et les deux fonctionnalités auraient placé un appel réseau à l'intérieur d'un outil dont la valeur repose sur l'absence de tout appel. ubuntils lui-même n'effectue toujours aucun appel réseau (voir l'intégration Wazuh pour la seule manière, désactivable, dont les découvertes peuvent quitter l'hôte, via un agent local).

v2.0.0 — séparation collect/analyze hors ligne

• ubuntils collect — acquiert un bundle inviolable (manifest.json + fichiers/commandes hachés) depuis un hôte actif, sans détection
• ubuntils analyze (BUNDLE | --root PATH) — exécute le même pipeline de détection/chronologie que scan contre un bundle ou une image montée, sans root requis
• bundle_integrity (live/ok/mismatch) exposé dans scan_metadata
• Lacunes de couverture de détection documentées en mode hors ligne (PROCESS_MASQUERADE, PROCESS_SUSPICIOUS_CONNECTION, et couverture réduite pour les chemins glob cron/sudoers/SSH et ExecStart des timers systemd)
• Détection fiable : scoring de confiance (confidence/confidence_band/signals), suppression --baseline, remplacement des heuristiques basées uniquement sur mtime dans SSH_UNAUTHORIZED_KEY/SHELL_RC_MODIFICATION par des signaux ctime + contenu, et une véritable chronologie hors ligne pour analyze BUNDLE et analyze --root
• Pack de couverture : PACKAGE_TAMPERED, IMMUTABLE_FLAG_SET, PAM_BACKDOOR, KERNEL_MODULE_SUSPICIOUS, SETUID_INVENTORY (via PackageCollector, PamCollector, KernelCollector ; tous en lecture seule par conception)
• 400 tests à 93,79 % de couverture

v2.1.0 — transmission SIEM

• Découvertes de ubuntils scan en direct transmises à un agent Wazuh local en JSONL, auto-détecté (aucun flag requis)
• Décodeur/règles Wazuh d'exemple et extrait <localfile> de ossec.conf (examples/wazuh/)
• Transmission intentionnellement limitée au scan en direct uniquement — ne se déclenche jamais pendant analyze hors ligne, car un bundle ou une image décrit un hôte différent de celui exécutant l'agent
• --no-wazuh pour exclure un scan de la transmission

v2.1.0 — durcissement (audit complet du code)

• Sécurité : la ré-exécution sudo ne transmet plus le PATH de l'appelant, et les commandes se résolvent sur un chemin sécurisé fixe ; les modifications sudoers sont vérifiées par visudo avant de toucher le fichier ; écritures de remédiation atomiques ; sortie de rapport/bundle sûre vis-à-vis des liens symboliques ; bundles extraits supprimés après analyze
• Couverture de détection : /etc/ld.so.preload analysé, entrées cron @reboot/@daily et scripts /etc/cron.{hourly,daily,weekly,monthly}, unités systemd .service et binaires ExecStart non détenus par root, règles sudoers %group et #include/@includedir, chaque élément d'une liste LD_PRELOAD
• Nouvelle règle USER_EMPTY_PASSWORD (compte de connexion sans mot de passe)
• Moins de faux positifs : vérifications de chemins délimitées par séparateurs, distinction setuid vs setgid, démons snap//usr/lib traités comme standard, KERNEL_MODULE_SUSPICIOUS rétrogradé en LOW, une découverte NSS par module
• Rapports honnêtes : règles échouées et collecteurs dégradés enregistrés dans scan_metadata et la TUI ; un échec de chronologie ne rejette plus les découvertes ; les bundles altérés avertissent et sortent avec le code 3 ; année/fuseau horaire syslog gérés correctement
• Remédiation plus sûre : barrière --min-confidence (défaut 40), résultats affichés dans la TUI après scan --remediate
• 444 tests à 94,29 % de couverture

v3.0.0 / v4.0.0 (exploratoire)

• Tableau de bord web pour le triage multi-hôtes
• Prise en charge de macOS

Contribution

Les contributions les plus utiles actuellement sont de nouvelles règles de détection (ajoutées comme fonctions autonomes dans detectors/rules.py avec un test correspondant), des collecteurs supplémentaires pour des types d'artefacts non encore couverts, des modules de remédiation pour SUSPICIOUS_SYSTEMD_TIMER et SHELL_RC_MODIFICATION (tous deux actuellement en lecture seule par conception, mais des chemins de remédiation automatique sûrs peuvent exister), des cas de test pour des cas limites sur des configurations Ubuntu spécifiques, et des améliorations de la documentation.

Ouvrez une issue avant de commencer une contribution importante pour éviter le travail en double.

Licence

MIT

Auteur

Créé par Asmit — BTech Computer Science, PES University, Bengaluru. L'outil est né de la frustration face au temps que prend le triage manuel d'Ubuntu comparé à ce qu'un script bien délimité peut automatiser.