auditd a fondo:

la telemetría de Linux que casi nadie configura bien

Serie Blue Team  |  unfantasmaenelsistema.com

En Windows, cuando alguien habla de telemetría para detección, la conversación gira enseguida hacia Sysmon: creación de procesos con línea de comandos, hashes, conexiones de red, todo en un canal ordenado. En Linux la respuesta equivalente lleva instalada por defecto en casi todas las distribuciones desde hace veinte años y se llama auditd, el demonio de espacio de usuario del subsistema de auditoría del kernel. El problema no es que falte: es que casi nadie lo configura más allá de las cuatro reglas que trae de fábrica, y esas cuatro reglas no detectan nada interesante.

Este artículo explica cómo está montado el subsistema de auditoría por dentro, la diferencia entre vigilar llamadas al sistema y vigilar ficheros, qué conjuntos de reglas de referencia merece la pena adoptar, cómo se leen los eventos sin perder la cabeza, cómo controlar el ruido y el impacto en rendimiento, y cómo enviar todo eso a un SIEM. El objetivo es que auditd deje de ser una casilla marcada en una auditoría de cumplimiento y pase a ser una fuente de detección de la que el equipo se fía.

1. Cómo está montado el subsistema de auditoría

La auditoría de Linux vive en el kernel. Hay un componente del núcleo que intercepta eventos —llamadas al sistema, accesos a ficheros vigilados, eventos de seguridad de otros subsistemas como SELinux— y los envía por un socket de tipo netlink a un único proceso de espacio de usuario. Ese proceso es auditd. Solo puede haber uno, y es quien decide qué se hace con cada registro: normalmente escribirlo en /var/log/audit/audit.log.

• Kernel audit: la maquinaria dentro del núcleo. No se configura directamente; se le cargan reglas desde el espacio de usuario.
• auditd: el demonio. Lee del kernel y persiste los eventos. Su comportamiento (rotación, acción cuando el disco se llena, formato) se ajusta en /etc/audit/auditd.conf.
• auditctl: la herramienta que carga y consulta reglas en caliente. `auditctl -l` lista las reglas activas; `auditctl -s` muestra el estado (pérdidas, backlog, tasa).
• augenrules: ensambla los ficheros de /etc/audit/rules.d/*.rules en el conjunto que se carga al arrancar. Es donde se dejan las reglas de forma persistente.
• ausearch y aureport: consulta y resumen del log. ausearch filtra por clave, usuario, syscall o rango de tiempo; aureport da recuentos y vistas agregadas.
• auditispd (dispatcher): reenvía una copia de cada evento a plugins —por ejemplo al que habla con syslog— para envío en tiempo real a un SIEM.

2. Dos formas de vigilar: syscalls y watches

Todas las reglas de auditoría se reducen a dos tipos, y confundirlos es la causa número uno de reglas que no disparan.

2.1 Reglas de llamada al sistema (-a)

Vigilan la ejecución de una syscall concreta, opcionalmente filtrada por argumentos: arquitectura, UID que la invoca, código de retorno, valor de un parámetro. Son la herramienta para detectar acciones: ejecutar un binario (execve), cargar un módulo del kernel (init_module, finit_module), cambiar la hora (adjtimex), montar un sistema de ficheros (mount).

# Toda ejecucion de un binario en sistemas de 64 bits, etiquetada 'exec'
-a always,exit -F arch=b64 -S execve -F key=exec
 
# Carga de modulos del kernel (persistencia / rootkits)
-a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -F key=modules
 
# Cambios de reloj (anti-forense)
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -F key=time-change

2.2 Watches de fichero o directorio (-w)

Vigilan accesos a una ruta: w escritura, a cambio de atributos, r lectura, x ejecución. Son la herramienta para detectar cambios de estado: que alguien toque /etc/passwd, /etc/sudoers, las unidades de systemd o los directorios de cron.

# Modificacion de cuentas y credenciales
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k scope
-w /etc/sudoers.d/ -p wa -k scope
 
# Persistencia por tareas programadas
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/systemd/system/ -p wa -k systemd-units
 
# Manipulacion de los propios logs y reglas de auditoria
-w /var/log/audit/ -p wra -k auditlog
-w /etc/audit/ -p wa -k auditconfig

Un watch es en realidad azúcar sintáctico: internamente se traduce a reglas de syscall sobre las llamadas de apertura y modificación filtradas por ese inodo. Por eso un watch sobre un directorio cubre los ficheros que ya contiene, pero conviene revisarlo tras cambios estructurales.

3. No empieces de cero: conjuntos de reglas de referencia

Escribir el conjunto de reglas a mano lleva semanas y siempre se olvida algo. Hay dos referencias maduras que conviene tomar como punto de partida y luego recortar.

El flujo recomendado: parte del conjunto de Neo23x0, cárgalo en un equipo de laboratorio representativo, deja pasar un día de uso normal y mira con aureport qué claves generan el 90 % del volumen. Esas son las candidatas a recortar o a filtrar antes de llevar el conjunto a producción.

# Colocar el fichero de reglas y regenerarlas
sudo cp audit.rules /etc/audit/rules.d/audit.rules
sudo augenrules --load
sudo auditctl -l | wc -l          # cuantas reglas activas
 
# Que claves generan mas eventos en el ultimo dia
sudo aureport --key --summary -ts today
 
# Ver el detalle de una clave concreta, ya interpretada
sudo ausearch -k modules -i -ts today

4. Leer un evento: campos clave y el execve legible

Un evento de auditoría no es una línea, es un grupo de registros que comparten un mismo identificador de evento (el par tiempo:serie que aparece como `msg=audit(1725360000.123:4567)`). Una ejecución de proceso genera al menos tres registros: SYSCALL (quién, qué syscall, resultado), EXECVE (los argumentos, uno por campo a0, a1, a2…) y PROCTITLE (el título del proceso). Los watches añaden un registro PATH por cada ruta implicada y un CWD con el directorio de trabajo.

El registro EXECVE guarda cada argumento por separado y, si contiene caracteres no imprimibles o espacios, lo codifica en hexadecimal. Leerlo en crudo es incómodo. La opción -i de ausearch (interpret) traduce UID a nombres, marcas de tiempo a fechas y decodifica esos argumentos; para reconstruir la línea de comando completa y legible se usa habitualmente el script aushape o utilidades como audisp-tools, y en el SIEM se normaliza a un único campo tipo process.command_line.

# Todas las ejecuciones de un usuario concreto hoy, interpretadas
sudo ausearch -ts today -ua alice -k exec -i
 
# Reconstruir un evento completo por su id
sudo ausearch -a 4567 -i
 
# Resumen de ejecutables mas vistos y de intentos fallidos de acceso
sudo aureport -x --summary
sudo aureport -f --summary --failed

5. Ruido, pérdidas y rendimiento

auditd puede llegar a ser caro. Cada syscall vigilada añade trabajo en una ruta caliente del kernel, y un conjunto de reglas mal recortado en un servidor con mucha actividad de ficheros puede generar gigabytes al día y, peor, perder eventos. El estado se consulta con `auditctl -s`.

La forma correcta de bajar el volumen no es quitar reglas de detección, es excluir explícitamente el ruido conocido con reglas de tipo exclude o con filtros por campo, dejándolo documentado.

# Excluir un tipo de evento entero que no aporta (ejemplo: CWD)
-a always,exclude -F msgtype=CWD
 
# No auditar la actividad de un servicio muy ruidoso por su uid dedicado
-a never,exit -F arch=b64 -F uid=vector -F key=exclude-vector
 
# Ignorar accesos de los propios procesos de monitorizacion a un directorio
-a never,exit -F dir=/var/lib/node_exporter -F key=exclude-metrics

6. Enviar la auditoría a un SIEM

El log local es para el forense en la máquina; la detección se hace en el SIEM. Hay tres caminos habituales para sacar los eventos en tiempo real, y todos parten del dispatcher de auditd.

Sea cual sea el transporte, en el SIEM hay dos tareas ineludibles: reensamblar los registros de un mismo evento en un documento único, y normalizar los campos (auid, exe, key) a tu esquema común para poder correlacionar con la telemetría de Windows y de red. Sin ese trabajo de normalización, auditd es un log que se consulta a mano, no una fuente de detección.

# Activar el reenvio por syslog del dispatcher
# /etc/audit/plugins.d/syslog.conf
active = yes
direction = out
path = builtin_syslog
type = builtin
args = LOG_INFO
format = string

7. Dónde encajan Sysmon for Linux y eBPF

auditd no es la única opción y no siempre es la mejor. Conviene saber qué aporta cada alternativa para combinarlas en lugar de elegir a ciegas.

• Sysmon for Linux (de Microsoft/Sysinternals, sobre eBPF) produce un esquema de eventos idéntico al de Sysmon en Windows: creación de proceso con línea de comandos ya montada, conexiones de red, creación de ficheros, carga de módulos. Si tu detección está construida sobre reglas estilo Sysmon (o Sigma con logsource de Sysmon), esto te da continuidad entre plataformas. Por dentro se apoya en el mismo subsistema audit o en eBPF según la versión del kernel.
• eBPF puro (Falco, Tetragon, Tracee) observa el kernel sin cargar módulos y con un coste por evento generalmente menor que las reglas de syscall de audit, además de dar contexto de contenedores y de red que auditd no tiene. Es el camino natural para hosts con muchos contenedores.
• auditd sigue siendo insustituible para lo que exige cumplimiento (es el mecanismo que citan STIG, CIS y PCI), para entornos donde no puedes desplegar eBPF, y por su granularidad fina sobre accesos a ficheros concretos. Muchos entornos maduros ejecutan auditd para watches de ficheros de sistema y eBPF/Falco para comportamiento en tiempo de ejecución.

8. Casos de uso concretos

Hazte inmune a la manipulación con la última línea del fichero de reglas: -e 2, que marca el conjunto como inmutable hasta el siguiente reinicio. A partir de ahí, cambiar las reglas exige reiniciar la máquina, y ese reinicio es en sí mismo una señal.

Conclusión

auditd ya está en tus servidores. La diferencia entre que sea una casilla de cumplimiento y que sea una fuente de detección real está en tres decisiones: adoptar un conjunto de reglas orientado a detección y mapeado a ATT&CK en lugar de las cuatro reglas por defecto, etiquetar cada regla con una clave estable para poder buscar, y hacer el trabajo de reensamblado y normalización en el SIEM en lugar de dejar el log tirado en cada máquina.

A partir de ahí, el mantenimiento es el mismo ciclo de siempre: medir el volumen por clave, excluir el ruido conocido con reglas estrechas y documentadas, vigilar el contador de eventos perdidos y sellar el conjunto con -e 2. Y donde auditd se queda corto —procesos, red, contenedores— complementarlo con Sysmon for Linux o con Falco sobre eBPF, no sustituirlo.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)