auditd responde a preguntas que solo surgen después del suceso: quién modificó este archivo, cuándo se creó este usuario, desde dónde se lanzó este proceso. Ninguna otra herramienta las responde: en los registros de las aplicaciones no está esa información, y el historial de comandos lo edita quien lo dejó.

La dificultad está en que instalar el paquete, por sí solo, no aporta nada. Reglas por omisión prácticamente no hay, el diario se escribe pero está vacío en lo esencial, y eso se descubre en el peor momento: cuando los datos hacen falta y no están.

Instalación

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

Una particularidad: en algunas versiones auditd no se reinicia con systemctl restart, el servicio se gobierna con su propio comando. Las reglas se releen así:

sudo augenrules --load
sudo auditctl -l

El segundo comando muestra lo que está realmente cargado. Créale a él, no al contenido de los archivos.

El conjunto de reglas

Las reglas se dejan en /etc/audit/rules.d/ como un archivo aparte. A continuación, un conjunto mínimo que se amortiza: responde a la mayoría de las preguntas de un incidente sin saturar el disco.

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## Usuarios y privilegios
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k privileges
-w /etc/sudoers.d/ -p wa -k privileges

## Acceso SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

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

## Módulos del núcleo
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

## Uso de sudo y su
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load

La sintaxis es breve: -w es una ruta a vigilar, -p wa significa reaccionar a escrituras y cambios de atributos, -p x a la ejecución, -k es la clave por la que se buscará después. Esas claves son la comodidad principal: sin ellas, buscar en el diario se convierte en revisar un gigabyte de texto.

Qué no entra en esa lista y por qué

Las guías proponen a menudo registrar todas las llamadas execve, es decir, cada arranque de cada programa. La tentación se entiende: una imagen completa de lo ocurrido. En la práctica, en un servidor en producción eso genera cientos de megabytes al día, consume una parte apreciable del procesador y obliga a recortar el diario antes de que haga falta. Si esa profundidad de detalle es necesaria, actívela de forma puntual: para un usuario, o mientras dure una investigación.

Lo mismo vale para vigilar el directorio del sitio: ahí se escribe sin parar, y la regla convierte el diario en un torrente de eventos sin sentido.

La lectura

Búsqueda por clave, con los identificadores numéricos resueltos en nombres:

sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today

La opción -i es imprescindible para la legibilidad: sin ella obtendrá números en lugar de nombres de usuario y de llamadas al sistema. -ts limita el periodo (today, recent o una fecha concreta).

Un resumen por periodo:

sudo aureport --summary -i
sudo aureport --auth -i --failed

En un registro de evento interesan tres campos: auid, el identificador del usuario que inició la sesión, uid, la identidad con la que se ejecutó la acción, y exe, el programa que la realizó. La diferencia entre auid y uid es la respuesta a «quién se convirtió exactamente en root»: uid=0 con el auid de una persona concreta señala al responsable sin ambigüedad, se hiciera pasar por quien se hiciera dentro de la sesión.

El disco

Los ajustes de volumen están en /etc/audit/auditd.conf:

max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG

Mire aparte disk_full_action. Algunas configuraciones traen por omisión la detención del sistema cuando el disco se llena: comportamiento justificado en máquinas con requisitos de auditoría y completamente fuera de lugar en un servidor web. Compruebe ese valor antes de que el disco se llene.

El modo de reglas inmutables

La línea -e 2 al final del archivo de reglas prohíbe cambiarlas hasta el reinicio, incluso a quien ha obtenido root. Eso eleva de forma notable el valor del diario: un intruso no puede desactivar la vigilancia sin reiniciar la máquina, y un reinicio se nota por sí mismo.

El reverso es evidente: usted tampoco podrá cambiar sus reglas sin reiniciar. Actívelo cuando el conjunto se haya asentado y haya convivido un mes con él.

Para qué en un servidor corriente

auditd no impide nada. Su valor se manifiesta exactamente una vez: cuando hay que reconstruir la secuencia de los hechos y los datos están o no están. No se recogen a posteriori, por eso el conjunto de reglas se pone de antemano y luego se deja en paz.

Una señal práctica de que el ajuste es correcto: la lista de reglas no está vacía, el diario no crece sin control, y los eventos con las claves identity y privileges aparecen rara vez y cada uno se puede explicar. Cómo se ve eso en una página lo muestra la demostración de abajo.