auditd audit.log: registro de auditoría del kernel

Qué es

El kernel de Linux tiene un subsistema de auditoría que emite registros para eventos relevantes para la seguridad: syscalls que coinciden con las reglas cargadas, vigilancias de archivos, cambios de configuración y mensajes enviados desde el espacio de usuario por PAM, sudo, sshd, useradd y programas similares. auditd recibe estos registros por netlink y los escribe en /var/log/audit/audit.log. Consulte la entrada del glosario sobre auditd.

Lo que acaba en el log depende por completo de las reglas. Sin reglas personalizadas se obtienen igualmente los eventos del espacio de usuario (inicios de sesión, autenticación, inicio y fin de sesión, cambios de cuentas, arranque y parada de servicios) más algunos eventos del kernel. Con reglas de execve o de vigilancia de archivos, audit.log se convierte en el registro de ejecución más detallado de un host Linux.

Dónde se encuentra

En los hosts sin auditd, algunos mensajes de auditoría del kernel siguen llegando al log del kernel y al journal (_TRANSPORT=audit), así que revise también el journal.

Qué prueba

• El ciclo de vida de la autenticación y las sesiones a través de PAM: USER_AUTH, USER_ACCT, CRED_ACQ, USER_LOGIN, USER_START, USER_END, con acct=, addr=, terminal= y res=success|failed.
• La ejecución de programas (cuando existe una regla de execve): los registros SYSCALL + EXECVE + CWD + PATH + PROCTITLE reconstruyen la línea de comandos completa y el directorio.
• La atribución a través de cambios de privilegio: auid es el UID de inicio de sesión fijado al hacer login y heredado a través de sudo y su, de modo que una shell de root iniciada por deploy sigue llevando el auid de deploy.
• La gestión de cuentas (ADD_USER, DEL_USER, ADD_GROUP, USER_MGMT, USER_CHAUTHTOK) y los comandos sudo (USER_CMD).
• La manipulación de la propia auditoría (CONFIG_CHANGE, DAEMON_START, DAEMON_END) y los cambios de reglas del cortafuegos (NETFILTER_CFG).
• No prueba nada que las reglas no cubrieran, y los builtins de la shell nunca generan registros execve.

Campos clave

Un evento execve típico (los registros comparten el mismo sello msg=audit(...)):

type=SYSCALL msg=audit(1789874047.512:8812): arch=c000003e syscall=59 success=yes exit=0 ppid=4190 pid=4302 auid=1001 uid=0 gid=0 euid=0 tty=pts0 ses=12 comm="curl" exe="/usr/bin/curl" key="exec"
type=EXECVE msg=audit(1789874047.512:8812): argc=3 a0="curl" a1="-o" a2="/tmp/.x"
type=CWD msg=audit(1789874047.512:8812): cwd="/root"
type=PROCTITLE msg=audit(1789874047.512:8812): proctitle=6375726C002D6F002F746D702F2E78

Con el valor por defecto de upstream log_format = ENRICHED, auditd añade campos traducidos tras un byte 0x1D (separador de grupo), en mayúsculas: AUID="deploy" UID="root" SYSCALL=execve. Estos nombres se resolvieron en el host original, lo que los hace más fiables que ausearch -i en una estación de análisis. Audit 2.x usaba RAW por defecto y las distribuciones pueden cambiar el valor, así que revise la configuración de la imagen.

Marcas de tiempo

msg=audit(1789874047.512:8812) contiene segundos de época Unix con una fracción de milisegundos, seguidos del número de serie del evento. Es UTC por naturaleza, así que no hace falta conversión de zona.

date -u -d @1789874047.512
ausearch -if audit.log -ts 09/20/2026 03:00:00 -te 09/20/2026 04:00:00 -i   # date format follows the analysis host's locale

El número de serie lo genera el kernel y se reinicia tras un reinicio, así que agrupe los registros por el sello completo sec.msec:serial, no solo por el número de serie.

Retención

auditd rota su propio log, no logrotate. El auditd.conf que distribuye upstream usa max_log_file = 8 (MiB), num_logs = 5 y max_log_file_action = ROTATE, es decir, unos 40 MiB de historial. Con la auditoría de execve en un servidor con mucha actividad, eso pueden ser horas. num_logs = 0 o una acción keep_logs cambian el comportamiento; space_left_action y disk_full_action deciden qué ocurre cuando se llena el disco (la configuración distribuida usa SYSLOG para space_left_action y SUSPEND, que deja de escribir en disco, para admin_space_left_action y disk_full_action).

Adquisición

# Dead box
cp -a /mnt/evidence/var/log/audit /mnt/evidence/etc/audit /cases/2026-017/

# Live, as root: also capture the loaded rules and status
auditctl -l > auditctl_rules.txt
auditctl -s > auditctl_status.txt
tar -C / -cpf /media/ir/audit.tar var/log/audit etc/audit

UAC recoge /var/log y ejecuta auditctl -l y auditctl -s en respuesta en vivo. Las reglas cargadas pueden diferir de los archivos en disco si alguien ejecutó auditctl -D o añadió reglas a mano.

Análisis

ausearch y aureport, del paquete audit, son las herramientas de referencia y funcionan sobre logs copiados con -if.

A=/cases/2026-017/audit
ausearch -if "$A" -m USER_LOGIN,USER_AUTH -i                  # logins and auth, interpreted
ausearch -if "$A" -m EXECVE -ul 1001 -i                        # everything run by login UID 1001
ausearch -if "$A" -k exec --format csv > exec.csv              # by rule key, for spreadsheets
ausearch -if "$A" -m CONFIG_CHANGE,DAEMON_END,DAEMON_START -i  # audit tampering
aureport -if "$A" --login --summary -i
aureport -if "$A" -x --summary                                 # executables

El plugin de parser text/selinux de Plaso incorpora audit.log a una super timeline. Zircolite (--auditd) aplica reglas Sigma para auditd de Linux sobre el log. Linux Log Parser lee en el navegador auth.log / secure, syslog, los archivos del journal, audit.log y wtmp / btmp / lastlog, y los combina en una sola cronología con las sesiones de inicio reconstruidas; no se sube nada.

Consejos para la investigación

• Antes de buscar, lea /etc/audit/rules.d/ en la imagen: la ausencia de reglas de execve o -w explica la falta de evidencias de ejecución mejor que una manipulación.
• -i traduce los UID con el /etc/passwd del equipo de análisis salvo que el log esté enriquecido. Contraste siempre los nombres con los archivos de cuentas de la propia imagen.
• auid sobrevive a sudo -i y su -, así que filtrar por auid recupera lo que un usuario hizo en una shell de root; compárelo con los logs de sudo y el historial de la shell.
• Busque auditctl -e 0, auditctl -D, systemctl stop auditd y ediciones bajo /etc/audit/ en los registros CONFIG_CHANGE y SYSCALL. El indicador de inmutabilidad (-e 2) impide cambiar las reglas hasta el reinicio, por lo que un reinicio inesperado justo antes de un incidente puede ser deliberado.
• Los valores ses vinculan todos los registros de un mismo login; emparéjelos con las sesiones de wtmp y con las líneas Accepted de auth.log.
• Menos generaciones rotadas de las que permite num_logs, en un host con actividad suficiente para haberlas llenado, sugiere un borrado. Compare el tamaño de los archivos con max_log_file.