ubuntils

CLI/TUI de Python para triaje forense de sistemas Ubuntu — detecta y remedia mecanismos de persistencia con recolección de artefactos, correlación de líneas de tiempo e integración con Wazuh.

Cuando sospechas que un sistema Linux ha sido comprometido, los primeros 30-40 minutos suelen dedicarse a ejecutar los mismos diez comandos en secuencia: revisar los procesos en ejecución, buscar tareas cron extrañas, hacer grep de LD_PRELOAD, escanear authorized_keys en busca de nuevas entradas, auditar sudoers. Cada paso es manual, implica cambiar de contexto y es propenso a errores bajo presión. Si te saltas una fuente — por ejemplo, /etc/sudoers.d/ en lugar de solo /etc/sudoers, o los crontabs de usuario además de /etc/cron.d/ — tendrás una imagen incompleta.

Las opciones existentes no resuelven esto de forma limpia. lynis es un auditor de endurecimiento, no una herramienta de triaje — informa debilidades de configuración en un sistema limpio y genera ruido en uno comprometido. chkrootkit y rkhunter buscan firmas de rootkits conocidos, pero son ciegos a técnicas de persistencia novedosas como temporizadores systemd abusados o entradas cron con apariencia legítima. Las consultas genéricas a un SIEM requieren una infraestructura de logs que puede no existir en el sistema que estás examinando. Y las suites forenses como Volatility se orientan a imágenes de memoria, no a una shell en vivo sobre un host en ejecución.

El vacío es una herramienta que se ejecute en el sistema en vivo ahora mismo, cubra los vectores de persistencia más comunes, correlacione la actividad entre fuentes de logs en una línea temporal y te diga exactamente qué revisar — sin requerir un agente externo, una base de datos ni conexión a internet.

Qué hace ubuntils

ubuntils se ejecuta en cuatro etapas secuenciales:

1. Recolección — Once recolectores reúnen artefactos forenses de forma concurrente desde /proc, tablas cron, unidades systemd, claves SSH, archivos sudoers, definiciones de entorno, integridad de paquetes (dpkg --verify), configuración de PAM/NSS y módulos del kernel cargados. Tarda aproximadamente 2,5 segundos en un sistema típico.
2. Detección — Un motor de detección ejecuta las dieciséis reglas integradas — más cualquier regla personalizada cargada con --rules — sobre los artefactos recolectados, produciendo una lista de hallazgos clasificada y con puntuación de confianza en aproximadamente un segundo.
3. Línea temporal — Un constructor de línea temporal lee syslog, journald y auditd en paralelo y correlaciona los eventos cronológicamente, añadiendo aproximadamente 0,3 segundos. Cada hallazgo se correlaciona automáticamente con la línea temporal, de modo que lleva consigo los eventos cercanos relacionados con él.
4. Salida — Los resultados aparecen ya sea en una TUI interactiva de cuatro pestañas (por defecto) o como JSON estructurado en stdout (--json).

ubuntils en sí no realiza llamadas de red, y todas las funciones — incluidas las reglas personalizadas y la correlación — se ejecutan contra artefactos recolectados localmente. La única forma en que los hallazgos pueden salir del host es la integración con Wazuh: si hay un agente Wazuh instalado, un scan en vivo escribe sus hallazgos en un archivo local que el agente luego envía a su gestor. Pasa --no-wazuh para desactivarlo durante una ejecución.

ubuntils scan no se ve afectado por todo lo que sigue — sigue siendo 100% en vivo, de un solo host, y cada flag existente funciona de forma idéntica. Dos comandos adicionales, collect y analyze, dividen el mismo pipeline de detección/línea temporal en un flujo de trabajo de adquirir-y-analizar apto para uso offline, para casos en los que no puedes (o no quieres) ejecutar la detección directamente en el host bajo investigación — consulta Análisis offline: collect y analyze más abajo, incluidas sus advertencias sobre la cobertura de detección.

Instalación

Ubuntu 22.04+ y cualquier sistema con PEP 668 (recomendado):

Ubuntu 22.04+ bloquea pip install a nivel de sistema. Usa pipx — gestiona el entorno de forma transparente para que nunca tengas que pensar en ello:```bash sudo apt install pipx -y cd ubuntils pipx install -e . ubuntils scan

ubuntils requiere root para acceder completamente a los artefactos. Si ejecutas ubuntils scan como un usuario no root, se reinvocará automáticamente con sudo usando el mismo intérprete de Python (por ruta absoluta), de modo que se utilice el entorno correcto sin reenviar tu PATH al proceso root. Cada comando externo (ss, dpkg, systemctl, …) se resuelve en una ruta de búsqueda fija propiedad de root, nunca tu PATH. Ejecutarlo sin root omitirá /etc/shadow, algunas entradas de /proc y archivos cron protegidos, y registrará advertencias por cada uno.

Inicio rápido

Solo detección — TUI interactiva:```bash sudo ubuntils scan

Detección con vista previa de remediación mediante CLI (ejecución en seco — sin aplicar cambios):```bash sudo ubuntils scan --remediate

Versión para imprimir:```bash ubuntils version

Analizar un paquete recopilado previamente (no se requiere root):```bash ubuntils analyze /path/to/bundle.tar.gz --json

Consulta Análisis offline: recopilar y analizar para conocer el formato del paquete y — lo que es más importante — qué no puede detectar el análisis offline en comparación con un scan en vivo.

Flags y configuración```

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

| -s | --server | SERVER | http://localhost:8080 | URL del servidor de escaneo | | -t | --token | TOKEN | - | Token de autenticación | | -o | --output | FILE | - | Archivo de salida | | -f | --format | FORMAT | json | Formato de salida (json, yaml, csv) | | -v | --verbose | - | false | Habilitar registro detallado | | -q | --quiet | - | false | Modo silencioso | | --timeout | - | SECONDS | 30 | Tiempo de espera de la solicitud | | --retry | - | COUNT | 3 | Número de reintentos | | --insecure | - | - | false | Omitir la verificación del certificado TLS |

Ejemplos

Configuración

La herramienta se puede configurar mediante un archivo de configuración o variables de entorno.

Archivo de configuración

Cree un archivo config.yaml en el directorio de trabajo:

Variables de entorno

Integración con CI/CD

GitHub Actions

GitLab CI

Solución de problemas

Problemas comunes

Error: No se puede conectar al servidor

Verifique que el servidor de escaneo esté en ejecución y sea accesible:

Error: Token de autenticación no válido

Asegúrese de que el token sea correcto y no haya expirado:

Error: Tiempo de espera de la solicitud agotado

Aumente el valor de tiempo de espera:

Registro de depuración

Habilite el registro detallado para solucionar problemas:

Contribución

Las contribuciones son bienvenidas. Por favor, consulte CONTRIBUTING.md para obtener más detalles.

Licencia

Este proyecto está licenciado bajo la Licencia MIT. Consulte el archivo LICENSE para obtener más detalles.```bash sudo ubuntils scan --json --config allowlist.yaml

| --no-color | Desactiva la salida en color | | --debug | Habilita el registro de depuración | | --verbose | Habilita el registro detallado | | --version | Muestra la versión del programa y sale | | --help | Muestra el mensaje de ayuda y sale |

Ejemplos

Salida

La herramienta genera un informe detallado que incluye:

• Información del objetivo: URL, dirección IP, puertos abiertos
• Tecnologías detectadas: Servidores web, frameworks, lenguajes de programación
• Vulnerabilidades encontradas: CVE ID, descripción, puntuación CVSS, referencias
• Recomendaciones: Pasos sugeridos para mitigar las vulnerabilidades

Contribuciones

¡Las contribuciones son bienvenidas! Por favor, sigue estos pasos:

1. Haz un fork del repositorio
2. Crea una rama para tu funcionalidad (git checkout -b feature/nueva-funcionalidad)
3. Realiza tus cambios y haz commit (git commit -am 'Añade nueva funcionalidad')
4. Haz push a la rama (git push origin feature/nueva-funcionalidad)
5. Abre un Pull Request

Licencia

Este proyecto está licenciado bajo la Licencia MIT - consulta el archivo LICENSE para más detalles.

Descargo de responsabilidad

Esta herramienta está destinada únicamente a fines educativos y de pruebas de seguridad autorizadas. Los autores no se hacen responsables del uso indebido o de los daños causados por esta herramienta. Utilízala únicamente en sistemas que poseas o para los que tengas permiso explícito de probar.

Créditos

• NVD - National Vulnerability Database
• CVE - Common Vulnerabilities and Exposures
• Shodan - Motor de búsqueda para dispositivos conectados a Internet```bash sudo ubuntils scan --json --rules custom_rules.yaml

Análisis sin conexión: recopilar y analizar

ubuntils scan ejecuta la recopilación, la detección y la línea de tiempo juntas contra el host en vivo. collect y analyze dividen ese flujo de trabajo en dos: collect adquiere un paquete a prueba de manipulación de un host (no se ejecuta detección), y analyze ejecuta la misma línea de detección/línea de tiempo utilizada por scan contra un paquete, o contra una imagen montada mediante --root, sin requerir root y sin volver a tocar el host original. Esto es para casos en los que deseas adquirir artefactos una vez y analizarlos más tarde, en otro lugar o repetidamente — o cuando estás realizando un triaje de una imagen de disco en lugar de un sistema en ejecución.

`ubuntils collect````bash

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

Toma una ruta de bundle como argumento posicional o --root PATH apuntando a una imagen montada / árbol de sistema de archivos extraído — no ambos. Ejecuta el mismo motor de detección, reglas personalizadas, allowlist y lógica de baseline que usa scan. No requiere root. El bundle se extrae a un directorio temporal privado que se elimina tan pronto como finaliza el análisis (puede contener /etc/shadow).

La cobertura difiere entre los dos modos offline, porque un bundle lleva el estado capturado reproducido desde el momento de collect mientras que --root solo tiene lo que esté presente en el sistema de archivos montado:

• analyze BUNDLE reproduce la salida real de los comandos ss/systemctl list-timers/journalctl capturada en el momento de collect, por lo que NetworkCollector y SystemdCollector producen hallazgos genuinos a partir de esa instantánea — no se omiten. La línea de tiempo se construye a partir del syslog/messages/audit.log/journalctl que el bundle capturó, por lo que está completamente poblada y los hallazgos obtienen una correlación real de related_events.
• analyze --root PATH apunta a una imagen muerta, montada, sin proceso activo ni estado del kernel que consultar, por lo que la ejecución de comandos se deshabilita por completo: NetworkCollector y SystemdCollector se omiten, registrándose en scan_metadata.command_collectors_skipped. La línea de tiempo aún se construye, pero a partir de los archivos de log estáticos presentes en la imagen (/var/log/syslog, /var/log/messages, /var/log/audit/audit.log) — la reproducción de journald no está disponible aquí ya que no hay un journalctl activo para consultar una imagen muerta.

Consulta Offline analysis: collect and analyze para la lista completa de brechas de cobertura de detección offline.

Formato del bundle

Un bundle es un tarball comprimido con gzip con todo bajo un prefijo 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

✓ marca éxito, ✗ marca fallo, el spinner marca el colector activo, y las filas en blanco están pendientes. Una vez que todos los colectores terminan y la detección + línea de tiempo se completan, la TUI cambia automáticamente a la pantalla de resultados.

Pantalla de resultados

La pantalla de resultados tiene cuatro pestañas que se navegan con las teclas numéricas:

Pulse q o Ctrl+C para salir.

Pestaña Resumen (tecla 1)

Muestra los metadatos del escaneo y los hallazgos principales en una sola pantalla:``` 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

Remediación dentro de la TUI

Para los hallazgos que tienen disponible una remediación automatizada, presione R mientras el hallazgo está seleccionado. Aparece un modal de confirmación:``` ┌─────────────────────────────────────────────────┐ │ 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 caso de fallo, el panel de detalles muestra el error. La copia de seguridad siempre se crea antes de intentar cualquier cambio.

Pulse Esc para contraer el panel de detalles.

Pestaña Timeline (tecla 3)

Una lista cronológica desplazable de eventos de registro correlacionados. Cada fila muestra la marca de tiempo, el origen y la descripción. Los eventos se extraen de syslog, journald y auditd y se deduplican.

Pestaña Stats (tecla 4)

Una vista resumida del escaneo: versión de Ubuntu detectada, arquitectura, duración del escaneo, número de recopiladores y fallos, y recuento de hallazgos por severidad junto con el total de eventos de la línea de tiempo.

Qué detecta

Por qué existe cada regla

CRON_ROOT_EXEC — Los crontabs de usuario se ejecutan como el propietario del crontab. Una entrada que invoca sudo o un intérprete propiedad de root significa que el usuario ha dispuesto que se ejecute código con privilegios de root de forma programada, sin necesidad de acceso sudo persistente. Esto sobrevive a los cambios de contraseña.

Ejemplo de hallazgo:``` [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 hace que el enlazador dinámico cargue una biblioteca compartida especificada antes que todas las demás, lo que permite la interceptación arbitraria de funciones en cualquier binario enlazado dinámicamente. Un valor que apunte fuera de las rutas de bibliotecas estándar es un indicador de rootkit en espacio de usuario casi seguro; se verifica cada biblioteca en una lista separada por espacios o dos puntos. /etc/ld.so.preload se inyecta en todos los procesos y está vacío en Ubuntu estándar, por lo que cualquier entrada allí se reporta — incluso una colocada dentro de /lib, un truco común de rootkit. La remediación elimina las entradas de /etc/ld.so.preload en lugar de comentarlas, porque el cargador no tiene sintaxis de comentarios en ese archivo.

Ejemplo de hallazgo:``` [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 — Una clave SSH recién añadida otorga acceso remoto persistente independientemente de las contraseñas. La ventana de 7 días detecta adiciones recientes mientras evita el ruido del aprovisionamiento inicial en sistemas más antiguos. Nota: la regla utiliza el mtime del archivo, que refleja la última escritura en el archivo authorized_keys, no la marca de tiempo de inserción de cada clave individual.

Ejemplo de hallazgo:``` [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 — Nombrar un binario malicioso con el nombre de un proceso del sistema conocido (sshd, python3, bash) es una técnica básica para evitar la detección en la salida de ps. Esta regla cruza el nombre del proceso de /proc/<pid>/status con la ruta resuelta del ejecutable de /proc/<pid>/exe. Las ubicaciones estándar incluyen /usr/local/{bin,sbin}, /usr/lib, /usr/libexec y /snap, por lo que systemd (/usr/lib/systemd/systemd) y los paquetes snap no la activan. Solo marca — matar un proceso requiere criterio humano.

Ejemplo de hallazgo:``` [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 — Una cuenta cuyo campo de contraseña en /etc/shadow está vacío no tiene contraseña alguna, y la pila PAM predeterminada de Ubuntu (pam_unix ... nullok) le permite iniciar sesión sin una. En una cuenta con un shell de inicio de sesión, eso es una puerta abierta. Solo marca — bloquéala con passwd -l mientras investigas.

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

SHELL_RC_MODIFICATION — Los archivos de inicialización del shell son un vector de persistencia fiable porque se ejecutan en cada inicio de sesión del usuario. Esta regla muestra las modificaciones recientes para revisión humana. Solo marca — el contenido del RC del shell requiere lectura antes de actuar sobre él.

Ejemplo de hallazgo:``` [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 — Los atacantes a menudo establecen el flag inmutable (i) o el flag de solo anexado (a) en archivos para impedir su modificación o eliminación, incluso por root, incluyendo para ocultar la manipulación de ediciones posteriores o la rotación de logs. Establecer estos flags en archivos sensibles del sistema como /etc/passwd, /etc/sudoers, /etc/pam.d/*, o los archivos de log auth/syslog/wtmp/btmp es un fuerte indicador de endurecimiento por parte del atacante. Esta regla detecta los flags inmutable y de solo anexado mediante lsattr contra esa lista fija de rutas sensibles. Solo flag — los cambios de flag requieren revisión humana.

Ejemplo de hallazgo:``` [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 — Los módulos del kernel se ejecutan en ring 0 con acceso sin restricciones. Los atacantes cargan con frecuencia módulos del kernel personalizados para rootkits, sniffing de paquetes u ocultación de procesos. Esta regla compara los módulos cargados actualmente con una pequeña lista de permitidos de módulos integrados esperados (comunes en la mayoría de los sistemas). Es de severidad LOW porque esa lista de permitidos es deliberadamente reducida. Nota: los hosts con mucho hardware, como controladores de GPU, tarjetas Wi-Fi o controladores propietarios, generarán falsos positivos. Los respondedores deben agregar los módulos esperados de su host mediante --config, permitiéndolos por nombre de módulo (usado como artifact_path). Solo marcado — la investigación de módulos del kernel requiere herramientas forenses y experiencia humana.

Ejemplo de hallazgo:``` [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

Salida JSON

--json escribe un único objeto JSON en stdout. No se imprime nada más.```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)" }

Salvaguardas

Cada remediación sigue el mismo patrón independientemente de cómo se active:

1. Detectar si la ruta del artefacto es un enlace simbólico — rechazar si lo es (evita que root escriba a través de enlaces simbólicos controlados por el atacante)
2. Crear una copia de seguridad con marca de tiempo en /var/backups/ubuntils/YYYYMMDD_HHMMSS/ con modo 0700
3. Validar el estado actual (la línea exacta debe seguir presente)
4. Aplicar el cambio mínimo posible — las entradas de cron y las claves se eliminan línea por línea; las líneas LD_PRELOAD en los archivos de inicio del shell se comentan; las entradas en /etc/ld.so.preload se eliminan (el cargador no tiene sintaxis de comentarios allí, por lo que una entrada comentada aún se cargaría). Para sudoers, el contenido editado se verifica con visudo -cf en una copia temporal antes de tocar el archivo real
5. Escribir de forma atómica — el nuevo contenido va a un archivo temporal junto al original (mismo modo y propietario), se hace fsync, y luego se renombra sobre él, de modo que un fallo a mitad de escritura no puede dejar un /etc/sudoers truncado
6. Verificar que la línea exacta ya no está

Si algún paso falla, la remediación se detiene inmediatamente, el sistema queda sin cambios, y se reporta el error completo con la ruta de la copia de seguridad y el comando de reversión. El acceso sudo está protegido de dos maneras: las reglas NOPASSWD de %group (como %sudo) son solo de marcado y nunca se eliminan automáticamente, y el remediador de sudoers se niega a eliminar la última regla del archivo sudoers principal.

Integración con Wazuh

ubuntils está diseñado para un triaje de un solo host y en un momento puntual — lo ejecutas cuando ya sospechas que algo va mal, y nunca se comunica con el exterior ni sigue vigilando después de que termina el escaneo. Eso es deliberado, pero también significa que un hallazgo de ubuntils vive solo en ese informe a menos que algo lo lleve más allá. La mayoría de los equipos que ejecutan Ubuntu a cualquier escala ya tienen un SIEM haciendo el lado continuo de la detección, así que en lugar de convertir ubuntils en su propio agente de monitorización de larga duración, entrega sus hallazgos al que probablemente ya ejecutas: Wazuh.

Si hay un agente de Wazuh presente en el host (existe /var/ossec/bin/wazuh-agentd o /var/ossec/etc/ossec.conf), ubuntils scan (a menos que se ejecute con --no-wazuh) añade cada hallazgo como una línea JSON a /var/log/ubuntils/wazuh-alerts.json para que el agente lo recoja — esto es un reenviador puro, no un módulo de Wazuh: sin llamada de red, sin clave de API, nada más que las mismas escrituras de artefactos locales que ubuntils ya realiza — aunque el agente, por supuesto, enviará esas líneas fuera del host a su gestor; ese es el objetivo. Se autodetecta sin necesidad de ningún flag (usa --no-wazuh para excluir una ejecución), de modo que un ubuntils scan programado o por script en una flota de hosts enrolados con el agente empieza a alimentar el SIEM inmediatamente sin cableado adicional. Esto nunca ocurre durante el ubuntils analyze offline (bundle o --root), ya que esos hallazgos describen un host diferente al que ejecuta el agente local de Wazuh — reenviar los hallazgos de un bundle al propio agente del analista los atribuiría a la máquina equivocada.

La intención es integrar ubuntils en una canalización de alertas/escalado existente en lugar de pedirle a un respondedor que cuide de una segunda herramienta: una vez cargadas las reglas de ejemplo de abajo, un hallazgo de ubuntils de severidad HIGH (una nueva cuenta UID-0, un rootkit LD_PRELOAD, una puerta trasera PAM) aparece como una alerta normal de Wazuh, hereda cualquier enrutamiento de notificaciones que el gestor ya tenga configurado, y se sitúa junto a cualquier otra señal en la misma línea temporal en lugar de en un archivo JSON independiente que alguien tiene que recordar revisar.

Para que Wazuh analice y genere alertas sobre estos hallazgos, copia las reglas de ejemplo de examples/wazuh/ en tu gestor de Wazuh, y añade el bloque <localfile> de examples/wazuh/ossec_localfile_snippet.xml al /var/ossec/etc/ossec.conf del agente. No se necesita instalar ningún decodificador personalizado: el localfile está configurado con log_format json, por lo que el decodificador JSON integrado de Wazuh analiza cada línea y mapea cada clave JSON de nivel superior k a data.k, con lo que local_rules.xml coincide directamente.

1. examples/wazuh/local_rules.xml → /var/ossec/etc/rules/ del gestor
2. El bloque <localfile> de examples/wazuh/ossec_localfile_snippet.xml → /var/ossec/etc/ossec.conf del agente
3. Reinicia ambos: systemctl restart wazuh-manager (gestor), systemctl restart wazuh-agent (host del agente)

Estas son solo plantillas de ejemplo, proporcionadas como punto de partida — no han sido probadas contra un gestor de Wazuh en vivo y deberían verificarse en un entorno que no sea de producción antes de confiar en ellas.

Esquema JSON por línea:

Recolectores

Dependencias de los recolectores

PackageCollector requiere tres herramientas estándar de Ubuntu en el host en vivo (dpkg, lsattr, find — todas presentes en instalaciones estándar de Ubuntu). Si algún comando no está disponible, PackageCollector produce grácilmente datos vacíos para esa porción en lugar de fallar. El análisis offline (analyze BUNDLE) reproduce la salida de comandos capturada en el momento de collect, por lo que no se requiere la disponibilidad de comandos en el host del analizador.

El escaneo find de setuid/setgid pasa -xdev para mantenerse acotado — no desciende a sistemas de archivos montados por separado (un montaje distinto bajo /opt, un /home montado por NFS, etc.). Esto es un compromiso deliberado entre tiempo de ejecución y cobertura: sin -xdev, el escaneo podría colgarse escaneando montajes de red o sistemas de archivos virtuales. Si tu entorno monta estas rutas en sistemas de archivos separados, ten en cuenta que no serán escaneadas.

dpkg --verify y el escaneo find de setuid/setgid usan tiempos de espera generosos no predeterminados (10 minutos y 5 minutos respectivamente, ver ubuntils/collectors/packages.py) ya que ambos pueden legítimamente ejecutarse bastante más allá del valor predeterminado de la biblioteca de 30 segundos en un host real con una base de datos de paquetes o árbol de archivos grande; ubuntils collect usa los mismos tiempos de espera al capturar estos comandos en un bundle.

Compatibilidad

Ejecutar sin root produce un escaneo parcial con advertencias. Rutas críticas como /etc/shadow, directorios de crontab protegidos, y algunas entradas de /proc serán omitidas.

Hoja de ruta

v1.0.0

• Los 8 recolectores
• Las 8 reglas de detección
• Constructor de línea temporal (syslog, journald, auditd)
• Pantalla de progreso de escaneo en vivo con ✓/✗ por recolector
• TUI interactiva de cuatro pestañas (Summary / Findings / Timeline / Stats)
• Remediación dentro de la TUI con modal de confirmación y worker en segundo plano
• Modo de salida JSON
• Remediación por CLI para 5 reglas con copia de seguridad, reversión y protección contra enlaces simbólicos
• Soporte para Ubuntu 20.04/22.04/24.04
• 240 pruebas con 90% de cobertura

v1.1.0

• Lista de permitidos de falsos positivos por id de regla o ruta (--config)
• --output FILE para escribir informes directamente
• Ventana temporal con --since
• Informes a prueba de manipulación (report_sha256, hostname, timestamp)
• Regla de detección USER_UID_ZERO

v1.5.0

• Reglas de detección personalizadas por coincidencia de patrones vía YAML (--rules)
• PROCESS_SUSPICIOUS_CONNECTION — correlación proceso↔red por PID
• Correlación automática hallazgo↔línea temporal (related_events)
• Remediación guiada para las tres reglas que requieren criterio
• 282 pruebas con 92% de cobertura

Las búsquedas de hash en VirusTotal y la exportación de IOC a MISP se descartaron de esta versión. VirusTotal solo responde para hashes conocidos — el caso que rkhunter ya cubre, y lo opuesto a la brecha de técnicas novedosas que ubuntils apunta — y ambas características habrían puesto una llamada de red dentro de una herramienta cuyo valor se basa en no hacer ninguna. ubuntils en sí mismo sigue sin hacer llamadas de red (ver la integración con Wazuh para la única forma opcional de que los hallazgos salgan del host, vía un agente local).

v2.0.0 — división offline collect/analyze

• ubuntils collect — adquiere un bundle a prueba de manipulación (manifest.json + archivos/comandos con hash) de un host en vivo, sin detección
• ubuntils analyze (BUNDLE | --root PATH) — ejecuta la misma canalización de detección/línea temporal que scan contra un bundle o una imagen montada, sin requerir root
• bundle_integrity (live/ok/mismatch) expuesto en scan_metadata
• Brechas de cobertura de detección documentadas en modo offline (PROCESS_MASQUERADE, PROCESS_SUSPICIOUS_CONNECTION, y cobertura reducida para rutas glob de cron/sudoers/SSH y ExecStart de temporizadores systemd)
• Detección fiable: puntuación de confianza (confidence/confidence_band/signals), supresión con --baseline, reemplazando heurísticas basadas solo en mtime en SSH_UNAUTHORIZED_KEY/SHELL_RC_MODIFICATION con señales de ctime + contenido, y una línea temporal offline real tanto para analyze BUNDLE como para analyze --root
• Paquete de cobertura: PACKAGE_TAMPERED, IMMUTABLE_FLAG_SET, PAM_BACKDOOR, KERNEL_MODULE_SUSPICIOUS, SETUID_INVENTORY (vía PackageCollector, PamCollector, KernelCollector; todos solo de marcado por diseño)
• 400 pruebas con 93.79% de cobertura

v2.1.0 — reenvío a SIEM

• Hallazgos de ubuntils scan en vivo reenviados a un agente local de Wazuh como JSONL, autodetectado (sin flag requerido)
• Decodificador/reglas de ejemplo de Wazuh y fragmento <localfile> de ossec.conf (examples/wazuh/)
• Reenvío intencionalmente limitado solo a scan en vivo — nunca se activa durante analyze offline, ya que un bundle o imagen describe un host diferente al que ejecuta el agente
• --no-wazuh para excluir un escaneo del reenvío

v2.1.0 — endurecimiento (auditoría completa del código base)

• Seguridad: la re-ejecución de sudo ya no reenvía el PATH del llamador, y los comandos se resuelven en una ruta segura fija; las ediciones de sudoers se verifican con visudo antes de tocar el archivo; escrituras de remediación atómicas; salida de informes/bundles segura frente a enlaces simbólicos; bundles extraídos eliminados después de analyze
• Cobertura de detección: /etc/ld.so.preload analizado, entradas de cron @reboot/@daily y scripts de /etc/cron.{hourly,daily,weekly,monthly}, unidades .service de systemd y binarios ExecStart no propiedad de root, reglas sudoers de %group y #include/@includedir, cada elemento de una lista LD_PRELOAD
• Nueva regla USER_EMPTY_PASSWORD (cuenta de inicio de sesión sin contraseña)
• Menos falsos positivos: comprobaciones de rutas delimitadas por separadores, setuid vs setgid diferenciados, demonios de snap//usr/lib tratados como estándar, KERNEL_MODULE_SUSPICIOUS degradado a LOW, un hallazgo NSS por módulo
• Informes honestos: reglas fallidas y recolectores degradados registrados en scan_metadata y en la TUI; un fallo de línea temporal ya no descarta hallazgos; bundles manipulados advierten y salen con código 3; año/zona horaria de syslog manejados correctamente
• Remediación más segura: puerta --min-confidence (predeterminado 40), resultados mostrados en la TUI después de scan --remediate
• 444 pruebas con 94.29% de cobertura

v3.0.0 / v4.0.0 (exploratorio)

• Panel web para triaje multi-host
• Soporte para macOS

Contribuir

Las contribuciones más útiles en este momento son nuevas reglas de detección (añadidas como funciones independientes en detectors/rules.py con una prueba correspondiente), recolectores adicionales para tipos de artefactos aún no cubiertos, módulos de remediación para SUSPICIOUS_SYSTEMD_TIMER y SHELL_RC_MODIFICATION (ambos actualmente solo de marcado por diseño, pero pueden existir rutas de auto-remediación seguras), casos de prueba para casos límite en configuraciones específicas de Ubuntu, y mejoras en la documentación.

Abre un issue antes de comenzar una contribución grande para evitar trabajo duplicado.

Licencia

MIT

Autor

Creado por Asmit — BTech en Ciencias de la Computación, PES University, Bengaluru. La herramienta surgió de la frustración con lo mucho que tarda el triaje manual de Ubuntu en comparación con lo que un script bien delimitado puede automatizar.