auditd es el demonio del sistema de auditoría de Linux: recibe del kernel un registro de los eventos que tú defines (cambios en archivos, llamadas al sistema, inicios de sesión) y los guarda en /var/log/audit/audit.log. A diferencia de los logs normales, un usuario no puede evitar que el kernel genere estos registros, por eso es la base de muchos requisitos de cumplimiento (PCI DSS, ISO 27001, CIS). En este tutorial instalarás auditd en Ubuntu 24.04, configurarás la rotación de sus logs, crearás un conjunto de reglas útil y aprenderás a consultar los eventos con ausearch y aureport.

Requisitos previos

  • Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath. En Debian 12 los pasos son idénticos; en Rocky Linux 9 auditd viene instalado de serie.
  • Un usuario no root con privilegios sudo.
  • Espacio libre en disco para los logs de auditoría (con la configuración de este tutorial ocupan como máximo unos 400 MB).

Paso 1: Instalar auditd

Instala el demonio y los plugins de despacho de eventos:

sudo apt update
sudo apt install auditd audispd-plugins

El paquete habilita e inicia el servicio automáticamente. Compruébalo:

sudo systemctl status auditd

● auditd.service - Security Auditing Service
     Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-09-25 10:12:03 UTC; 8s ago

Consulta el estado del subsistema de auditoría del kernel:

sudo auditctl -s

enabled 1
failure 1
pid 2154
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
...

enabled 1 indica que la auditoría está activa y lost 0 que no se ha perdido ningún evento.

Paso 2: Configurar el demonio y la rotación de logs

El comportamiento del demonio se define en /etc/audit/auditd.conf. Ábrelo:

sudo nano /etc/audit/auditd.conf

Revisa y ajusta estas claves (el resto puede quedarse con su valor por defecto):

log_file = /var/log/audit/audit.log
log_format = ENRICHED
flush = INCREMENTAL_ASYNC
freq = 50
max_log_file = 50
num_logs = 8
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND

Qué hace cada una:

  • log_format = ENRICHED añade a cada evento los nombres de usuario y de llamada al sistema, además de los números, lo que facilita leerlos en otra máquina.
  • max_log_file = 50 y num_logs = 8 rotan el log cada 50 MB y conservan 8 archivos, unos 400 MB en total.
  • space_left y admin_space_left están en MB libres en la partición del log. Con menos de 75 MB se escribe un aviso en syslog; con menos de 50 MB auditd deja de escribir para no llenar el disco.

Aplica los cambios. auditd vuelve a leer su configuración cuando recibe la señal SIGHUP:

sudo systemctl kill -s SIGHUP auditd

Verifica que no ha habido errores:

sudo journalctl -u auditd -n 5 --no-pager

Paso 3: Entender la sintaxis de las reglas

Las reglas persistentes se guardan en archivos .rules dentro de /etc/audit/rules.d/. El script augenrules los concatena en orden alfabético en /etc/audit/audit.rules y los carga en el kernel. Hay dos tipos de regla:

TipoSintaxisUso
Vigilancia de archivo-w RUTA -p PERMISOS -k CLAVECambios o accesos a un archivo o directorio
Llamada al sistema-a always,exit -F arch=b64 -S LLAMADA -F FILTRO -k CLAVEAcciones concretas del kernel (ejecutar, cargar módulos, cambiar la hora)

Los permisos de -p son r (lectura), w (escritura), x (ejecución) y a (cambio de atributos). La clave -k es una etiqueta libre que después usarás para buscar.

En los filtros de llamadas al sistema aparece a menudo auid, el identificador del usuario que inició sesión originalmente. Se mantiene aunque ese usuario ejecute sudo, así que permite saber quién hizo algo como root. -F auid>=1000 -F auid!=unset limita la regla a usuarios humanos y excluye procesos del sistema.

Ubuntu incluye un archivo base, /etc/audit/rules.d/audit.rules, que borra las reglas previas (-D) y fija el tamaño del búfer (-b 8192). Déjalo como está.

Paso 4: Vigilar archivos críticos

Crea un archivo de reglas para los archivos de identidad y configuración más sensibles:

sudo nano /etc/audit/rules.d/50-archivos.rules

## Usuarios, grupos y contraseñas
-w /etc/passwd -p wa -k identidad
-w /etc/group -p wa -k identidad
-w /etc/shadow -p wa -k identidad
-w /etc/gshadow -p wa -k identidad

## Privilegios sudo
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

## Configuración de SSH
-w /etc/ssh/sshd_config -p wa -k sshd
-w /etc/ssh/sshd_config.d/ -p wa -k sshd

## Tareas programadas
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Configuración del propio sistema de auditoría
-w /etc/audit/ -p wa -k auditconfig

Se usa -p wa (escritura y atributos) en lugar de vigilar también las lecturas: /etc/passwd se lee continuamente y registrar cada lectura llenaría el log sin aportar información.

Paso 5: Auditar llamadas al sistema

Crea un segundo archivo con reglas de llamadas al sistema:

sudo nano /etc/audit/rules.d/60-syscalls.rules

## Comandos ejecutados como root por usuarios humanos (incluye sudo)
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k comandos_root
-a always,exit -F arch=b32 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k comandos_root

## Carga y descarga de módulos del kernel
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k modulos

## Cambios de la hora del sistema
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k cambio_hora

## Cambios de nombre de host
-a always,exit -F arch=b64 -S sethostname,setdomainname -k cambio_hostname

## Accesos denegados a archivos
-a always,exit -F arch=b64 -S open,openat,creat,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k acceso_denegado
-a always,exit -F arch=b64 -S open,openat,creat,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k acceso_denegado

Las reglas de execve se duplican con arch=b32 porque un programa de 32 bits podría ejecutar comandos a través de las llamadas al sistema de 32 bits y saltarse la regla de 64 bits.

Paso 6: Cargar las reglas y hacerlas inmutables

Opcionalmente, bloquea la configuración para que nadie pueda modificar las reglas sin reiniciar el servidor. Con -e 2 un atacante con acceso root no puede desactivar la auditoría en caliente. Este archivo debe ser el último en orden alfabético:

echo "-e 2" | sudo tee /etc/audit/rules.d/99-finalize.rules

Carga las reglas en el kernel:

sudo augenrules --load

Lista las reglas activas para confirmar que se han cargado:

sudo auditctl -l

-w /etc/passwd -p wa -k identidad
-w /etc/group -p wa -k identidad
...
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=-1 -k comandos_root
...

Si activaste el modo inmutable, sudo auditctl -s mostrará enabled 2.

Paso 7: Probar las reglas y buscar eventos

Genera un evento creando y borrando un usuario de prueba:

sudo useradd auditdemo
sudo userdel auditdemo

Busca los eventos con la clave identidad. La opción -i traduce los identificadores numéricos (UID, llamadas al sistema) a nombres legibles:

sudo ausearch -k identidad -i --start recent

----
type=PROCTITLE msg=audit(25/09/26 10:31:44.218:612) : proctitle=useradd auditdemo
type=PATH msg=audit(25/09/26 10:31:44.218:612) : item=1 name=/etc/passwd inode=1452 nametype=CREATE ...
type=SYSCALL msg=audit(25/09/26 10:31:44.218:612) : arch=x86_64 syscall=rename success=yes exit=0 ... auid=your_user uid=root ... comm=useradd exe=/usr/sbin/useradd key=identidad

El campo auid=your_user muestra quién hizo el cambio aunque el proceso se ejecutara como uid=root.

Otras búsquedas habituales:

# Comandos ejecutados como root hoy
sudo ausearch -k comandos_root -i --start today

# Inicios de sesión fallidos
sudo ausearch -m USER_LOGIN --success no -i

# Eventos de un usuario concreto por su UID
sudo ausearch -ua 1000 -i --start today

Paso 8: Generar informes con aureport

aureport resume el log en informes. Empieza por el resumen general:

sudo aureport --summary

Summary Report
======================
Range of time in logs: 25/09/26 10:12:03.114 - 25/09/26 10:40:12.871
Selected time for report: 25/09/26 10:12:03 - 25/09/26 10:40:12.871
Number of changes in configuration: 14
Number of changes to accounts, groups, or roles: 4
Number of logins: 2
Number of failed logins: 3
Number of authentications: 5
Number of failed authentications: 3
...

Informes útiles para una revisión periódica:

# Autenticaciones fallidas
sudo aureport -au --failed -i

# Eventos agrupados por clave de regla
sudo aureport -k --summary

# Ejecutables más frecuentes en los eventos
sudo aureport -x --summary

Solución de problemas

auditctl -s muestra lost mayor que 0. El kernel descarta eventos porque el búfer se llena. Aumenta -b en /etc/audit/rules.d/audit.rules (por ejemplo a 16384) y reduce el ruido de las reglas más frecuentes.

augenrules --load devuelve The audit system is in immutable mode, no rule changes allowed. Tienes -e 2 activo. Edita las reglas y reinicia el servidor para que se apliquen.

El log crece demasiado rápido. Localiza qué regla genera más eventos con sudo aureport -k --summary y restríngela con filtros -F (usuario, ruta o resultado).

Conclusión

Tienes auditd registrando cambios en usuarios, sudo, SSH y cron, los comandos que se ejecutan como root y los accesos denegados, con rotación de logs controlada. Como siguientes pasos, puedes enviar los eventos a un servidor central con el plugin audisp-remote para que no se puedan borrar en local, revisar las reglas de ejemplo que incluye el paquete en /usr/share/doc/auditd/examples/rules/ o comparar tu configuración con el benchmark CIS de Ubuntu 24.04.