--- title: "Cómo configurar auditd en Ubuntu 24.04 con reglas útiles" description: "Instala auditd en Ubuntu 24.04, crea reglas para vigilar cuentas, sudo, SSH y comandos de root, bloquea la configuración y consulta los eventos con ausearch." category: "Cumplimiento de las normas" language: es source: https://cubepath.com/es/docs/cumplimiento-de-las-normas/auditoria-con-auditd-configuracion-avanzada updated: 2026-09-25 --- # Cómo configurar auditd en Ubuntu 24.04 con reglas útiles 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`: ```bash sudo apt update sudo apt install auditd ``` El servicio se habilita y arranca automáticamente. Compruébalo: ```bash sudo systemctl status auditd --no-pager ``` ```output ● 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: ```bash sudo auditctl -s ``` ```output 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: ```bash 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: ```ini GRUB_CMDLINE_LINUX="audit=1 audit_backlog_limit=8192" ``` Aplica el cambio. Tendrá efecto en el próximo reinicio: ```bash 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: ```bash sudo nano /etc/audit/auditd.conf ``` Localiza y cambia estas claves (el resto déjalas como están): ```ini 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. > Nota: Algunas normas exigen que el sistema no siga funcionando sin auditoría. En ese caso usa `HALT` en `admin_space_left_action` y `disk_full_action`, sabiendo que el servidor se apagará si el disco se llena. El servicio de auditd en Ubuntu no permite `systemctl restart`. Para que relea la configuración, envíale la señal `SIGHUP`: ```bash sudo pkill -HUP -x auditd ``` Comprueba en el journal que ha recargado la configuración y que no hay errores: ```bash 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: ```bash sudo nano /etc/audit/rules.d/50-servidor.rules ``` Añade este contenido: ```text ## 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: ```bash sudo augenrules --load sudo auditctl -l ``` ```output -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: ```bash sudo nano /etc/audit/rules.d/99-finalizar.rules ``` ```text -e 2 ``` Cárgalo y comprueba el estado: ```bash sudo augenrules --load sudo auditctl -s | grep enabled ``` ```output 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: ```bash sudo useradd auditprueba sudo userdel auditprueba ``` Busca los eventos con la clave `identidad`. La opción `-i` traduce identificadores numéricos a nombres: ```bash sudo ausearch -k identidad -i --start today ``` ```output ---- 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: ```bash # 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 ``` ```output 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: ```bash 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.