Cuando queremos saber qué ocurrió realmente en un servidor Linux, los logs tradicionales no siempre bastan. journald, syslog o los logs de una aplicación suelen decirnos que algo pasó, pero no necesariamente quién abrió un archivo sensible, qué proceso ejecutó una llamada al sistema o qué identidad de login estaba detrás de una acción.

Ahí entra Linux Audit y su daemon de espacio de usuario: auditd.

La idea central es sencilla:

auditd convierte eventos de auditoría producidos por el kernel y otros componentes del sistema en un registro persistente que luego podemos consultar e investigar.

No es un firewall y no bloquea ataques por sí solo. Su valor está en la trazabilidad: responder mejor a preguntas como quién hizo qué, cuándo, con qué proceso y sobre qué recurso.

La arquitectura mental: del kernel al log

Una forma útil de verlo es así:

Usuario / proceso
      │
      ▼
Kernel Linux
      │
      ├── syscalls
      ├── cambios de archivos
      ├── autenticación
      ├── eventos de seguridad
      └── reglas de auditoría
      │
      ▼
Linux Audit subsystem
      │
      ▼
auditd
      │
      ▼
/var/log/audit/audit.log
      │
      ├── ausearch  -> búsqueda de eventos
      └── aureport  -> resúmenes e informes

La página de manual de auditd lo describe como el componente de espacio de usuario del Linux Auditing System encargado de escribir los registros de auditoría a disco. También deja claro el reparto de responsabilidades: ausearch y aureport sirven para leer los datos, mientras que auditctl permite controlar el sistema de auditoría y cargar reglas.

¿Dónde guarda auditd los eventos?

La ubicación habitual es:

/var/log/audit/audit.log

Pero no conviene asumirla a ciegas. El daemon se configura en:

/etc/audit/auditd.conf

Podemos confirmar el archivo configurado con:

grep '^log_file' /etc/audit/auditd.conf

En una instalación típica veremos algo parecido a:

log_file = /var/log/audit/audit.log

auditd.conf también controla aspectos importantes como rotación, tamaño máximo del log y qué hacer cuando queda poco espacio en disco. Esto importa mucho en servidores: una auditoría muy agresiva puede generar un volumen considerable de eventos.

El error común: pensar que una línea equivale a un evento

El formato de Linux Audit puede resultar extraño al principio porque un evento lógico puede estar compuesto por varios registros.

Por ejemplo, una misma operación podría producir registros de tipos distintos:

SYSCALL
CWD
PATH
EXECVE
PROCTITLE

Todos pertenecen al mismo evento si comparten el mismo identificador en un campo parecido a:

msg=audit(1788895200.123:8421)

Podemos interpretarlo conceptualmente como:

1788895200.123 -> instante del evento
8421           -> número/serial del evento

Por eso hacer simplemente:

cat /var/log/audit/audit.log

sirve para inspección puntual, pero no es la mejor forma de investigar. Hay que reconstruir los registros que pertenecen al mismo evento, y ausearch ya sabe hacerlo.

Qué significan los tipos de registro más comunes

SYSCALL

Describe una llamada al sistema y aporta información sobre el proceso que la realizó.

Puede incluir datos como:

pid
ppid
uid
euid
auid
exe
success
exit

PATH

Identifica archivos o rutas relacionados con la operación.

Un mismo evento puede tener más de un registro PATH.

CWD

Indica el directorio de trabajo actual del proceso.

EXECVE

Guarda información sobre la ejecución de un programa y sus argumentos cuando ese tipo de auditoría está presente.

USER_LOGIN, USER_AUTH y eventos relacionados

Ayudan a seguir autenticaciones, sesiones y operaciones de identidad.

uid no siempre es la identidad que buscas: fíjate en auid

Uno de los campos más interesantes para investigación es auid, el Audit User ID.

Supongamos que un usuario inicia sesión y después usa sudo para ejecutar algo como root. Durante la operación podemos encontrar:

uid=0

porque el proceso efectivo está ejecutándose como root.

Pero el auid puede conservar la identidad asociada al login original. Esa diferencia es extremadamente útil para reconstruir acciones administrativas.

La idea práctica es:

uid / euid -> identidad actual o efectiva del proceso
auid       -> identidad de auditoría asociada a la sesión de login

No todos los eventos tendrán todos estos campos, pero cuando están presentes conviene entender la diferencia.

Antes de buscar: comprobar que auditd está funcionando

Podemos revisar el servicio:

sudo systemctl status auditd

Y consultar el estado del subsistema de auditoría:

sudo auditctl -s

Para ver las reglas cargadas actualmente:

sudo auditctl -l

Esto es importante porque auditd solo puede registrar aquello que el kernel genera y lo que nuestras reglas hayan pedido auditar, además de los eventos que el sistema produce de forma inherente.

Leer eventos con ausearch

ausearch es normalmente el punto de entrada más cómodo para investigar los logs.

Eventos desde hoy

sudo ausearch -ts today

Eventos recientes

sudo ausearch -ts recent

Intentos de login

sudo ausearch -m USER_LOGIN

Intentos de login fallidos

sudo ausearch -m USER_LOGIN --success no -i

La opción -i o --interpret intenta convertir determinados valores numéricos en una representación más legible.

Acciones asociadas a un Audit User ID

Por ejemplo, para auid 1000:

sudo ausearch -ua 1000 -i

Buscar por una key definida en una regla

sudo ausearch -k passwd_changes

Las keys son especialmente prácticas porque permiten etiquetar reglas con nombres humanos en vez de recordar syscalls o filtros complejos.

Crear una regla sencilla para vigilar un archivo

Como ejemplo educativo podemos vigilar escrituras y cambios de atributos sobre /etc/passwd:

sudo auditctl -w /etc/passwd -p wa -k passwd_changes

Donde:

-w /etc/passwd       -> recurso vigilado
-p wa                -> write + attribute changes
-k passwd_changes    -> etiqueta para buscar después

Luego:

sudo ausearch -k passwd_changes -i

nos permite recuperar los eventos relacionados.

Hay una distinción importante: una regla añadida directamente con auditctl es adecuada para pruebas y diagnóstico, pero para configuración persistente normalmente se utilizan archivos de reglas bajo:

/etc/audit/rules.d/

que posteriormente se compilan/cargan mediante el mecanismo de reglas de Audit de la distribución, frecuentemente augenrules.

aureport: cuando queremos el bosque y no cada árbol

ausearch es excelente para reconstruir eventos concretos. aureport sirve mejor para obtener resúmenes.

Un informe general:

sudo aureport

Autenticaciones:

sudo aureport -au

Eventos relacionados con archivos:

sudo aureport -f

Comandos ejecutados, en versiones que soportan esa opción:

sudo aureport --comm

Una característica útil es que los informes incluyen números de evento que después podemos usar para volver al detalle con ausearch.

El workflow termina siendo:

1. aureport detecta algo interesante
2. obtenemos el número de evento
3. ausearch recupera el evento completo
4. interpretamos SYSCALL + PATH + identidad + proceso

auditd frente a journald: no hacen exactamente lo mismo

No conviene ver auditd como un reemplazo de journald.

journald es excelente para preguntas como:

¿Qué dijo este servicio?
¿Por qué falló esta unidad de systemd?
¿Qué escribió la aplicación en stdout/stderr?

Linux Audit está pensado para otro tipo de preguntas:

¿Qué proceso tocó este archivo?
¿Qué identidad estaba detrás de la operación?
¿Qué syscall se ejecutó?
¿Qué regla de seguridad disparó este registro?

En una investigación real normalmente usamos ambos.

Qué conviene auditar en un servidor

Más reglas no significa automáticamente más seguridad. Una configuración demasiado amplia puede producir ruido, consumir disco y hacer más difícil encontrar los eventos realmente importantes.

Un enfoque razonable es empezar por recursos de alto valor, por ejemplo:

/etc/passwd
/etc/shadow
/etc/sudoers
/etc/ssh/sshd_config
claves y archivos de configuración críticos
cambios de usuarios y grupos
operaciones administrativas relevantes

La selección concreta depende del rol del servidor y del modelo de amenazas.

También hay que proteger los propios logs

Los registros de auditoría solo son útiles si podemos confiar en ellos.

Por eso, en un entorno serio también debemos pensar en:

  • permisos del directorio y de los archivos de Audit;
  • rotación y retención;
  • espacio disponible en disco;
  • envío remoto o centralización cuando el riesgo lo justifique;
  • alertas ante eventos especialmente sensibles;
  • una política clara para evitar que el volumen de logs se convierta en un problema operacional.

auditd incluso dispone de opciones de configuración para reaccionar ante situaciones de poco espacio o errores de escritura. No conviene dejar esos valores al azar en sistemas críticos.

Un pequeño workflow de investigación

Si llegamos a un servidor y queremos entender rápidamente su estado de auditoría, podemos empezar así:

# 1. ¿Está activo?
sudo systemctl status auditd

# 2. ¿Dónde escribe?
grep '^log_file' /etc/audit/auditd.conf

# 3. ¿Qué reglas están cargadas?
sudo auditctl -l

# 4. ¿Qué ha ocurrido recientemente?
sudo ausearch -ts recent -i

# 5. ¿Cómo se ve el resumen general?
sudo aureport

# 6. ¿Qué autenticaciones aparecen?
sudo aureport -au

Con solo esos pasos ya podemos responder muchas preguntas que serían incómodas de reconstruir únicamente con logs de aplicaciones.

La idea que merece quedarse

auditd no es simplemente “otro archivo de logs”.

Es la pieza de espacio de usuario de un sistema de auditoría que conecta eventos del kernel con evidencia persistente e investigable.

La separación de herramientas también ayuda a entenderlo:

auditctl  -> define/controla qué auditar
 auditd   -> recibe y persiste registros
ausearch  -> busca eventos completos
aureport  -> resume la actividad

Cuando aparece la pregunta “¿quién hizo esto en el servidor?”, Linux Audit es una de las primeras herramientas que deberíamos saber consultar.

Referencias