auditd es el demonio del sistema de auditoría del kernel de Linux. Registra en /var/log/audit/audit.log los eventos que tú defines con reglas: quién modificó /etc/passwd, qué comandos ejecutó alguien como root, quién cambió la hora del sistema o cargó un módulo del kernel. A diferencia de los logs de aplicación, cada evento incluye el usuario original de la sesión (auid), que se mantiene aunque la persona use sudo o su. En este tutorial instalarás auditd en Ubuntu 24.04, ajustarás su almacenamiento, crearás un conjunto de reglas útil para auditorías tipo PCI DSS o ISO 27001 y aprenderás a consultar los eventos.

Requisitos previos

  • Un servidor con Ubuntu 24.04 LTS de 64 bits (x86_64), por ejemplo un VPS de CubePath. En Debian 12 los pasos son iguales.
  • Un usuario no root con privilegios sudo.
  • Unos cientos de megabytes libres en /var/log para los logs de auditoría.

Paso 1: Instalar auditd

Instala el paquete auditd, que incluye el demonio y las herramientas auditctl, augenrules, ausearch y aureport:

sudo apt update
sudo apt install auditd

El servicio se habilita y arranca automáticamente. Compruébalo:

sudo systemctl status auditd --no-pager

● 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:02:11 UTC; 12s ago

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

sudo auditctl -s

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

enabled 1 indica que la auditoría está activa. Vigila el valor lost: si sube, el kernel está descartando eventos porque llegan más rápido de lo que auditd los escribe.

Para que también se auditen los procesos que arrancan antes que auditd, activa la auditoría desde el arranque del kernel. Edita la configuración de GRUB:

sudo nano /etc/default/grub

Añade audit=1 audit_backlog_limit=8192 a la línea GRUB_CMDLINE_LINUX, manteniendo lo que ya tenga:

GRUB_CMDLINE_LINUX="audit=1 audit_backlog_limit=8192"

Aplica el cambio. Tendrá efecto en el próximo reinicio:

sudo update-grub

Paso 2: Ajustar el almacenamiento de los logs de auditoría

auditd rota su propio log; no usa logrotate. Por defecto en Ubuntu guarda 5 ficheros de 8 MB, lo que en un servidor con actividad puede cubrir solo unos días. Edita el fichero de configuración:

sudo nano /etc/audit/auditd.conf

Localiza y cambia estas claves (el resto déjalas como están):

log_format = ENRICHED
max_log_file = 50
num_logs = 10
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG
admin_space_left = 100
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
  • max_log_file y num_logs: 10 ficheros de 50 MB, unos 500 MB en total. Ajústalo a tu política de retención.
  • log_format = ENRICHED: añade al log los nombres de usuario y de llamada al sistema resueltos, útil si analizas el log en otra máquina.
  • space_left y admin_space_left (en MB libres del disco): con poco espacio se avisa en syslog; con el mínimo crítico, auditd deja de escribir en lugar de llenar el disco.

El servicio de auditd en Ubuntu no permite systemctl restart. Para que relea la configuración, envíale la señal SIGHUP:

sudo pkill -HUP -x auditd

Comprueba en el journal que ha recargado la configuración y que no hay errores:

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

Paso 3: Entender el formato de las reglas

Las reglas persistentes se guardan en ficheros .rules dentro de /etc/audit/rules.d/. Al cargarlas, augenrules las une en orden alfabético en /etc/audit/audit.rules, por eso se usan prefijos numéricos. Ubuntu ya incluye audit.rules con las opciones base (-D para borrar reglas previas, -b 8192 para el tamaño del búfer).

Hay dos tipos de reglas:

  • Vigilancia de ficheros (-w): -w /etc/passwd -p wa -k identidad registra escrituras (w) y cambios de atributos (a) sobre ese fichero. También existen r (lectura) y x (ejecución).
  • Llamadas al sistema (-a always,exit): registran una llamada al sistema cuando se cumplen unos filtros. -F arch=b64 indica la arquitectura, -S la llamada y -F filtra por campos como auid o euid.

La opción -k asigna una etiqueta (clave) a la regla. Es lo que usarás después para buscar los eventos.

Paso 4: Crear las reglas de auditoría

Crea un único fichero con las reglas del sistema:

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

Añade este contenido:

## Cuentas y grupos
-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
-w /etc/security/opasswd -p wa -k identidad

## Permisos de 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

## Cambios de hora del sistema
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k hora
-w /etc/localtime -p wa -k hora

## Carga y descarga de módulos del kernel
-a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k modulos
-w /usr/bin/kmod -p x -k modulos

## Comandos ejecutados como root por usuarios que iniciaron sesión
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k comandos_root

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

## Cambios en la propia configuración de auditoría
-w /etc/audit/ -p wa -k config_auditoria
-w /var/log/audit/ -p wa -k logs_auditoria

Algunas decisiones importantes de este conjunto:

  • auid>=1000 -F auid!=unset limita las reglas de comandos y accesos denegados a personas que han iniciado sesión, e ignora los servicios del sistema. Sin este filtro, execve generaría miles de eventos por minuto.
  • No se audita cada execve ni cada connect de todo el sistema: es un error habitual que satura el disco y hace que se pierdan eventos (lost en auditctl -s).
  • Si ejecutas binarios de 32 bits, duplica las reglas de llamadas al sistema cambiando arch=b64 por arch=b32.

Carga las reglas y comprueba que no hay errores de sintaxis:

sudo augenrules --load
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 una regla tiene un error, augenrules muestra la línea afectada y el resto de reglas se cargan igualmente. Corrige el fichero y vuelve a ejecutar el comando.

Paso 5: Hacer la configuración inmutable

Un atacante con acceso root podría desactivar las reglas con auditctl -D para no dejar rastro. El modo inmutable impide cambiar las reglas hasta el siguiente reinicio. Crea un fichero que se cargue el último:

sudo nano /etc/audit/rules.d/99-finalizar.rules

-e 2

Cárgalo y comprueba el estado:

sudo augenrules --load
sudo auditctl -s | grep enabled

enabled 2

A partir de aquí, cualquier cambio de reglas requiere reiniciar el servidor. Mientras estés ajustando reglas, deja este paso para el final.

Paso 6: Generar eventos y consultarlos

Crea y borra un usuario de prueba, que modifica /etc/passwd y ejecuta comandos como root:

sudo useradd auditprueba
sudo userdel auditprueba

Busca los eventos con la clave identidad. La opción -i traduce identificadores numéricos a nombres:

sudo ausearch -k identidad -i --start today

----
type=PROCTITLE msg=audit(09/25/2026 10:31:07.412:1284) : proctitle=useradd auditprueba
type=PATH msg=audit(09/25/2026 10:31:07.412:1284) : item=1 name=/etc/passwd inode=3934 nametype=CREATE ...
type=SYSCALL msg=audit(09/25/2026 10:31:07.412:1284) : arch=x86_64 syscall=rename success=yes exit=0 ... auid=tu_usuario uid=root euid=root ... comm=useradd exe=/usr/sbin/useradd key=identidad

Fíjate en auid=tu_usuario: aunque el comando se ejecutó como root con sudo, el evento identifica a la persona que inició sesión.

Otras consultas habituales:

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

# Eventos de un usuario concreto (por su UID de inicio de sesión)
sudo ausearch -ua 1000 -i --start this-week

# Resumen general y resumen por clave
sudo aureport --summary
sudo aureport -k --summary

# Intentos de autenticación fallidos
sudo aureport -au --failed

Key Summary Report
===========================
total  key
===========================
412  comandos_root
37  identidad
5  sshd
2  acceso_denegado

aureport es útil para una revisión periódica, y ausearch para investigar un incidente concreto.

Paso 7: Revisar el rendimiento

Tras unas horas de uso normal, comprueba que no se pierden eventos y cuánto crece el log:

sudo auditctl -s | grep -E 'lost|backlog'
sudo ls -lh /var/log/audit/

Si lost es mayor que 0 o backlog se acerca a backlog_limit, las reglas son demasiado amplias. Busca qué clave genera más eventos con aureport -k --summary y restringe esa regla con filtros -F (por usuario, directorio o resultado). Si ya aplicaste el paso 5, reinicia el servidor después de cambiar las reglas.

Solución de problemas

  • Operation refused, unit auditd.service may be requested by dependency only: ocurre con systemctl restart auditd o stop. Es intencionado; usa sudo pkill -HUP -x auditd para recargar la configuración, o reinicia el servidor.
  • Error sending add rule data request (Operation not permitted): la configuración está en modo inmutable (enabled 2). Reinicia para aplicar las reglas nuevas.
  • Syscall name unknown: la llamada al sistema no existe en esa arquitectura (por ejemplo, open en arm64). Usa openat o elimina esa llamada de la regla.
  • Los eventos muestran auid=unset: el proceso no viene de un inicio de sesión (un servicio o una tarea de cron del sistema). Es normal y las reglas con auid!=unset los ignoran.

Conclusión

Tienes auditd registrando los cambios de cuentas, sudo, SSH, hora y módulos del kernel, los comandos ejecutados como root por cada persona y los accesos denegados, con la configuración protegida contra cambios. Como siguientes pasos, envía los eventos a un servidor central con el plugin de syslog (paquete audispd-plugins, fichero /etc/audit/plugins.d/syslog.conf) para que no se puedan borrar desde el propio servidor, define una revisión periódica con aureport y ajusta num_logs a la política de retención de tu organización.