auditd en Debian 13 sin destruir discos: ajustes prácticos para auditoría sensata

El modelo mental: qué hace realmente auditd en tu máquina

auditd no es un “escritor de archivos de log”. Es un colector en espacio de usuario para el subsistema de auditoría del kernel. Las reglas que cargas indican al kernel qué eventos emitir. Esos eventos aterrizan en una cola del kernel (el backlog) y luego son extraídos por auditd, formateados y escritos—habitualmente en /var/log/audit/audit.log. Si los envías a otro lugar, en la mayoría de configuraciones todavía existen localmente primero.

El dolor en disco viene de dos fuentes:

• Volumen de eventos: demasiadas llamadas al sistema auditadas o rutas vigiladas, especialmente en rutas calientes de código (gestores de paquetes, runtimes de contenedores, sistemas de build, servidores web que escriben archivos temporales).
• Patrón de escritura: los registros de auditoría son pequeños y frecuentes. Pequeños apéndices algo síncronos más actualizaciones de metadatos pueden convertirse en un generador de escrituras aleatorias dependiendo del sistema de archivos, opciones de montaje y comportamiento de rotación.

La auditoría del kernel también es implacable con la corrección. Si el backlog se desborda, puedes perder eventos. Si configuras “panic on failure”, puedes dejar caer toda la máquina. Al cumplimiento le encanta la segunda opción; operaciones la odia; terminarás negociando.

Aquí está la verdad dura: no puedes “optimizar” un conjunto de reglas de auditoría que no has acotado. Si partes de una base enorme que audita cada openat() y cada execve() en cada host, obtendrás muchos datos—y mucho calor. Tu trabajo es decidir qué preguntas necesitas responder durante un incidente, luego auditar con la precisión suficiente para responderlas de forma fiable.

Una cita que se sostiene en operaciones: “La esperanza no es una estrategia.” — idea parafraseada atribuida a practicantes de fiabilidad. En auditoría, la esperanza es “lo encendemos en todas partes y filtramos después”. No lo harás. Te ahogarás primero.

Algunos datos e historia útil

• La auditoría en Linux precede a la mayoría de herramientas “cloud native”. El Linux Audit Framework existe desde mediados de los 2000, pensado para entornos regulados que necesitaban trazas a prueba de manipulación.
• SELinux y audit crecieron conjuntamente. Mucha adopción temprana de audit vino de entornos que ya desplegaban SELinux y necesitaban trazas de eventos para decisiones de política y depuración de la aplicación de políticas.
• La tubería de auditoría es primero kernel, segundo demonio. Si el espacio de usuario no puede mantenerse al día, la cola del kernel se acumula; el demonio no es la única pieza en movimiento.
• Las “watch rules” (-w) son basadas en rutas y caras en su propio sentido. Son geniales para un conjunto pequeño de archivos críticos; son una trampa para directorios enteros con alto churn.
• Las reglas de syscalls pueden explotar más rápido de lo esperado. Auditar aperturas de archivos en un host ocupado es el clásico DoS autoinfligido, porque todo abre archivos constantemente.
• Los logs de auditoría son estructurados-ish, no hechos para humanos primeramente. El log bruto está pensado para herramientas como ausearch y aureport, no para hacer grep a las 3 a. m. (aunque lo harás de todas formas).
• Audit tiene una historia real de “fail closed”. Con audit=1 y ajustes estrictos, los sistemas pueden configurarse para tratar la falla de auditoría como fatal. No es teórico; la gente lo hace.
• Debian históricamente tendió a ser conservador por defecto. Normalmente no obtienes un conjunto masivo de reglas “gratis”. El daño usualmente viene de baselines de cumplimiento copiados que no fueron probados con tu carga de trabajo.

Broma #1: Los logs de auditoría son como brillo (glitter)—una vez que despliegas una regla ruidosa, la encontrarás por todos lados durante meses.

Cómo luce la “auditoría sensata” en producción

Antes de tocar configuraciones, define objetivos. Si no, discutirás sin fin con Seguridad sobre “eventos faltantes” sin saber qué significa “suficiente”.

Objetivos operativos (prácticos, medibles)

• No amplificación sostenida de escrituras en disco por auditoría. Picos cortos están bien; la agitación constante no. Tu presupuesto de resistencia del SSD es real.
• No impacto de latencia significativo en servicios críticos. Mide latencia p99 antes y después de habilitar auditoría bajo carga representativa.
• No pérdida de eventos de auditoría bajo carga normal. Bajo carga de incidente (fork bomb, disco lleno), decides la política: descartar eventos, limitar o fallar cerrado.
• Los logs de auditoría son consultables e interpretables. Si hace falta un especialista para responder “quién cambió la config de SSH”, tu sistema se pudrirá.

Objetivos de seguridad (lo que realmente quieres saber)

• Acciones administrativas: creación de usuarios, uso de sudo, cambios de privilegios.
• Cambios relacionados con credenciales y autenticación: llaves SSH, configuración PAM, /etc/shadow.
• Ejecución de binarios sensibles: sudo, su, gestores de paquetes, gestores de servicios.
• Cambios en configuración crítica: subconjunto de /etc, unidades systemd, cron, la configuración de audit misma.
• Acciones del kernel/módulos donde sea relevante: carga/descarga de módulos en hosts donde importa.

Si necesitas “detección de exfiltración de datos”, auditd por sí solo no es tu herramienta. Puede contribuir (por ejemplo, vigilando acceso a un archivo clave), pero no es un DLP de red.

Guía rápida de diagnóstico (caza de cuellos de botella en minutos)

Cuando alguien dice “auditd está matando los discos”, no discutas. Ejecuta un playbook corto y deja que el equipo te diga lo que pasa.

Primero: ¿es volumen de eventos o comportamiento del disco?

• Revisa la tasa de eventos de auditoría y la salud del backlog.
• Revisa patrones de IO en disco (IOPS, latencia, profundidad de cola).
• Revisa si las reglas son intensivas en syscalls o en watches de rutas.

Segundo: identifica la regla o la carga culpable

• Encuentra las claves de auditoría más calientes (si usaste keys).
• Correlaciona timestamps: picos de auditoría vs despliegues de servicios vs cron vs rotación de logs.
• Busca directorios de alto churn que estén siendo vigilados.

Tercero: decide la perilla de compromiso que vas a girar

• Reducir eventos: acotar reglas, añadir filtros, quitar watches de directorios.
• Reducir el dolor de escritura: ajustar flush/freq, rotación, filesystem separado, evitar opciones de montaje patológicas.
• Aumentar buffering: ajustes de backlog, pero comprende memoria y semántica de pérdida.
• Cambiar comportamiento ante fallos: ¿descartar eventos bajo presión o degradar el host?

Tareas prácticas (comandos, salida, decisiones)

Estos son chequeos reales y ejecutables. Cada uno termina con una decisión: mantener, cambiar o escalar. Hazlos en orden la primera vez; luego desarrollarás instintos.

Tarea 1: Confirma que la auditoría está habilitada y el demonio está sano

cr0x@server:~$ systemctl status auditd --no-pager
● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 09:12:01 UTC; 2h 3min ago
       Docs: man:auditd(8)
   Main PID: 712 (auditd)
      Tasks: 4
     Memory: 3.2M
        CPU: 1min 22s

Qué significa: Está en ejecución. Si está reiniciándose, probablemente tienes errores de configuración o problemas de disco lleno.

Decisión: Si está inactivo/fallado, arregla la salud del servicio primero (espacio en disco, sintaxis de config, permisos) antes de afinar reglas.

Tarea 2: Revisa el estado de auditoría del kernel: backlog, modo de fallo, estado habilitado

cr0x@server:~$ sudo auditctl -s
enabled 1
failure 1
pid 712
rate_limit 0
backlog_limit 8192
lost 0
backlog 12
backlog_wait_time 60000

Qué significa: La auditoría está habilitada. El backlog está mayormente vacío (backlog 12). failure 1 significa comportamiento “printk”; existen modos más estrictos.

Decisión: Si lost está aumentando, estás perdiendo eventos de auditoría—trátalo como incidente en hosts con alcance de cumplimiento.

Tarea 3: Mide rápidamente el volumen de eventos de auditoría (tasa aproximada)

cr0x@server:~$ sudo awk 'BEGIN{c=0} {c++} END{print c}' /var/log/audit/audit.log
184223

Qué significa: Conteo bruto en el archivo actual. Combínalo con la marca de tiempo del archivo para estimar el throughput.

Decisión: Si este número crece a una velocidad insana (cientos de miles por hora en un host pequeño), probablemente tienes reglas de syscalls demasiado amplias.

Tarea 4: Revisa qué claves de auditoría son las más activas (solo funciona si usaste -k)

cr0x@server:~$ sudo aureport --summary --key | head
Key Summary Report
=========================================
total  file
=========================================
15432  ssh-config
12011  priv-esc
 8430  pkg-mgr
 4122  cron

Qué significa: Puedes ver qué grupos de reglas generan más eventos.

Decisión: Si una clave domina, inspecciona las reglas detrás de ella. Reduce alcance o añade exclusiones.

Tarea 5: Identifica rutas vigiladas de alto churn (watch rules)

cr0x@server:~$ sudo auditctl -l | sed -n '1,12p'
-w /etc/ssh/sshd_config -p wa -k ssh-config
-w /etc/sudoers -p wa -k priv-esc
-w /etc/sudoers.d/ -p wa -k priv-esc
-w /var/log/ -p wa -k logdir
-a always,exit -F arch=b64 -S execve -F euid=0 -k root-exec

Qué significa: Ese -w /var/log/ es un letrero de neón que dice “Disfruto el dolor”. Vigilar directorios enteros de logs tiene mucho churn.

Decisión: Elimina watches de directorios en rutas de alta actividad (/var/log, /tmp, almacenamiento de contenedores). Reemplaza por archivos específicos o filtros de syscalls.

Tarea 6: Revisa la presión de IO en disco y la latencia

cr0x@server:~$ iostat -xz 1 3
Linux 6.12.0-1-amd64 (server)  12/30/2025  _x86_64_ (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.12    0.00    1.55    6.78    0.00   88.55

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
nvme0n1          2.10  820.0    45.0  9320.0    4.12   5.05  92.30

Qué significa: Escritos por segundo muy altos, utilización alta. Eso es consistente con apéndices pequeños de logs.

Decisión: Si w/s es enorme y await sube durante picos de auditoría, estás limitado por disco. Reduce volumen de eventos y/o suaviza escrituras con ajustes de auditd y separación de sistemas de archivos.

Tarea 7: Verifica filesystem y opciones de montaje del log de auditoría

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /var/log/audit
/dev/mapper/vg0-varlog ext4 rw,relatime,errors=remount-ro

Qué significa: Los logs de auditoría están en ext4 con relatime. Eso es razonable.

Decisión: Si los logs de auditoría comparten un filesystem root ocupado, considera seriamente un filesystem dedicado para /var/log o /var/log/audit para que las escrituras de auditoría no compitan con bases de datos o capas de contenedores.

Tarea 8: Confirma que journald no esté duplicando el problema

cr0x@server:~$ sudo journalctl -u auditd -n 20 --no-pager
Dec 30 10:11:22 server auditd[712]: Audit daemon started successfully
Dec 30 10:14:05 server auditd[712]: Audit backlog limit exceeded
Dec 30 10:14:05 server auditd[712]: Audit events lost

Qué significa: Estás viendo presión en el backlog. Journald no es mayormente el log de auditoría, pero capturará las quejas de auditd.

Decisión: Si el backlog se excede, necesitas reducir la tasa de eventos o aumentar capacidad (backlog/CPU), no “rotar logs más fuerte”.

Tarea 9: Observa live los contadores lost y backlog

cr0x@server:~$ watch -n 1 'sudo auditctl -s | egrep "lost|backlog |backlog_limit|backlog_wait_time"'
Every 1.0s: sudo auditctl -s | egrep "lost|backlog |backlog_limit|backlog_wait_time"  server: Tue Dec 30 11:16:02 2025

backlog_limit 8192
lost 0
backlog 23
backlog_wait_time 60000

Qué significa: Si backlog sube y se mantiene alto, auditd no puede drenar eventos lo suficientemente rápido.

Decisión: Si el backlog sube durante trabajos específicos (por ejemplo, backups), acota reglas para que esos trabajos no generen eventos irrelevantes.

Tarea 10: Encuentra los tipos de registro más habladores en audit.log

cr0x@server:~$ sudo awk '{print $2}' /var/log/audit/audit.log | cut -d'=' -f2 | sort | uniq -c | sort -nr | head
 88421 SYSCALL
 60210 PATH
  9102 CWD
  3210 EXECVE

Qué significa: Mucho SYSCALL y PATH sugiere que la auditoría por syscalls es la mayor parte. Eso es normal; la pregunta es si es demasiado amplia.

Decisión: Si las entradas PATH dominan, puede que estés auditando aperturas/atributos de archivos ampliamente. Acierta las reglas con filtros de directorio/archivo y restricciones por auid/euid.

Tarea 11: Confirma la política de rotación para logs de auditoría

cr0x@server:~$ sudo grep -E '^(max_log_file|num_logs|max_log_file_action|space_left_action|admin_space_left_action|disk_full_action|flush|freq)' /etc/audit/auditd.conf
max_log_file = 50
num_logs = 10
max_log_file_action = ROTATE
space_left_action = SYSLOG
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
flush = INCREMENTAL_ASYNC
freq = 50

Qué significa: La rotación está habilitada. flush = INCREMENTAL_ASYNC con freq=50 reduce la presión de sincronización mientras aún limita la ventana de pérdida.

Decisión: Si ves flush = SYNC en hosts ocupados, espera dolor. Si ves num_logs demasiado alto con archivos enormes, podrías estar acumulando localmente sin beneficio.

Tarea 12: Valida que los archivos de reglas realmente estén cargados (y no duplicados)

cr0x@server:~$ sudo augenrules --check
No change

Qué significa: Las reglas compiladas coinciden con lo que hay en disco. No hay cambios pendientes.

Decisión: Si informa cambios, recarga reglas de forma controlada; evita recargas en caliente durante tráfico pico si usas modo inmutable.

Tarea 13: Revisa si las reglas son inmutables (y por tanto difíciles de arreglar en caliente)

cr0x@server:~$ sudo auditctl -s | grep enabled
enabled 1

cr0x@server:~$ sudo auditctl -e 2
Error sending enable request (Operation not permitted)

Qué significa: Si ya estás en modo inmutable (-e 2 establecido al arrancar), no puedes cambiar reglas sin reiniciar.

Decisión: Usa el modo inmutable solo en sistemas donde esa restricción operativa sea aceptable y probada. De lo contrario, estás a una mala baseline de una larga noche.

Tarea 14: Revisa indicadores de desgaste del SSD (chequeo de sanidad, no paranoia)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'percentage|data units written|wear|media'
Percentage Used:                    3%
Data Units Written:                 8,421,332 [4.31 TB]
Media and Data Integrity Errors:    0

Qué significa: Puedes correlacionar crecimiento de escrituras con la activación de la auditoría. No adivines; mide.

Decisión: Si la pendiente de “Data Units Written” cambia bruscamente tras habilitar auditoría, trátalo como un problema de planificación de capacidad y ajústalo en consecuencia.

Tarea 15: Encuentra los ejecutables más ruidosos (culpables comunes: gestores de paquetes y orquestación)

cr0x@server:~$ sudo ausearch -m SYSCALL -ts today | grep -oE 'exe="[^"]+"' | sort | uniq -c | sort -nr | head
  812 exe="/usr/bin/dpkg"
  640 exe="/usr/bin/apt"
  418 exe="/usr/bin/python3.12"
  251 exe="/usr/sbin/cron"

Qué significa: Tienes picos ligados a actividad de paquetes y jobs cron. Eso no es malo; es predecible.

Decisión: Si auditas mucho la actividad de gestores de paquetes, acepta picos durante ventanas de parches—o añade reglas con ámbito temporal u host-specific para flotas de parcheo.

Tarea 16: Genera un informe “quién tocó /etc/shadow” (prueba de que la auditoría funciona)

cr0x@server:~$ sudo ausearch -f /etc/shadow -ts this-week | aureport -f -i | head
File Report
===============================================
# date time            file                 syscall success exe                  auid event
===============================================
1. 12/29/2025 02:10:12 /etc/shadow           openat  yes     /usr/sbin/usermod    admin  19402

Qué significa: Este es el tipo de pregunta que la auditoría debe responder rápido. Si no puede, tus reglas son o muy débiles o muy desordenadas.

Decisión: Mantén reglas que respondan preguntas reales de incidentes. Elimina reglas que generan calor pero no cambian decisiones.

Reglas que no derriten discos: estrategia y ejemplos

Las reglas de auditoría son donde los discos van a morir. La mayor parte del consejo de “ajuste de auditd” es simplemente “apaga la auditoría”. Eso es perezoso. La jugada real es pasar de cobertura amplia de syscalls a cobertura estrecha y dirigida por intención.

Principio 1: Prefiere watches dirigidos para archivos críticos, no directorios ocupados

Vigilar /etc/shadow es barato y útil. Vigilar /var/log es una carta de DoS que te autocorrespondiste.

Buenos ejemplos de watch:

• /etc/passwd, /etc/shadow, /etc/group
• /etc/sudoers, /etc/sudoers.d/
• /etc/ssh/sshd_config y posiblemente /etc/ssh/sshd_config.d/
• /etc/audit/ (sí, vigila al vigilante)
• Archivos de unidad systemd que realmente te importan: /etc/systemd/system/

Principio 2: Si auditas syscalls, filtra por identidad e intención

Auditar execve para cada usuario en un servidor de build generará una pequeña novela cada minuto. En su lugar:

• Audita ejecuciones privilegiadas (euid=0) iniciadas por usuarios reales (auid>=1000).
• Audita cambios (escrituras/cambios de atributo) a un conjunto pequeño de filesystems o directorios.
• Excluye cuentas de ruido conocidas (backup, monitoring) si la política lo permite—y documenta esa excepción.

Principio 3: Usa claves religiosamente

Las claves (-k) no son decoración. Son cómo haces triage. Sin claves, te quedarás mirando registros crudos y sentirás que tu alma te abandona.

Un conjunto base sensato (opinión)

En Debian, las reglas se gestionan normalmente vía /etc/audit/rules.d/*.rules y se compilan a /etc/audit/audit.rules usando augenrules.

Ejemplo: /etc/audit/rules.d/10-sane-baseline.rules (ilustrativo, no maximal):

cr0x@server:~$ sudo cat /etc/audit/rules.d/10-sane-baseline.rules
## Identity and auth files
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group  -p wa -k identity
-w /etc/gshadow -p wa -k identity

## Sudoers and SSH
-w /etc/sudoers -p wa -k priv-esc
-w /etc/sudoers.d/ -p wa -k priv-esc
-w /etc/ssh/sshd_config -p wa -k ssh-config
-w /etc/ssh/sshd_config.d/ -p wa -k ssh-config

## Audit configuration itself
-w /etc/audit/ -p wa -k audit-config

## Systemd unit overrides (where persistence happens)
-w /etc/systemd/system/ -p wa -k systemd-units
-w /etc/systemd/system.conf -p wa -k systemd-units
-w /etc/systemd/journald.conf -p wa -k logging

## Cron persistence
-w /etc/cron.d/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Privileged command execution by real users
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k root-exec
-a always,exit -F arch=b32 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k root-exec

Este baseline hace algunas cosas importantes:

• Se enfoca en persistencia y privilegio, que son relevantes en incidentes.
• Evita la auditoría por syscalls de apertura de archivos. Ahí es donde el volumen de eventos se vuelve feroz.
• Etiqueta todo con claves para que puedas triangular en minutos.

Dónde la gente se equivoca: reglas syscall “audita todo”

Un baseline de cumplimiento común audita el acceso a archivos ampliamente, a menudo con algo como “auditar todos los fallos de open/openat”, o “auditar todas las escrituras por cualquiera”. En un sistema Linux moderno, eso es básicamente auditar el acto de respirar.

Si debes auditar escrituras de archivos, hazlo de forma estrecha:

• Directorios específicos que contienen secretos o datasets regulados.
• Cuentas de servicio específicas que interaccionan con esos datos.
• Sólo escrituras/ cambios de atributos exitosos, a menos que el fallo sea una señal de seguridad en tu entorno.

Controles de ruido que deberías usar realmente

Puedes filtrar patrones de ruido conocidos usando campos como auid, uid, exe y dir. La trampa: cada filtro que añades es también un punto ciego futuro. Asegúrate de que la exclusión sea una decisión de política, no una comodidad.

Ejemplo: excluir un usuario de agente de backup dedicado del ruido de root-exec (solo si tu equipo de seguridad está de acuerdo):

cr0x@server:~$ sudo cat /etc/audit/rules.d/20-exclusions.rules
## Exclude known automation account from root-exec noise
-a never,exit -F arch=b64 -S execve -F auid=1105 -k exclude-backup
-a never,exit -F arch=b32 -S execve -F auid=1105 -k exclude-backup

Broma #2: La forma más rápida de descubrir un camino de código “raro” es auditarlo en producción.

Ajustes del demonio auditd que importan (y por qué)

Las reglas deciden el volumen. auditd.conf decide cuán doloroso es persistir ese volumen y qué ocurre cuando las cosas salen mal.

Estrategia de flush: el anillo de humor de tu disco

Ajustes clave:

• flush: cómo auditd vacía datos a disco.
• freq: con qué frecuencia vaciar cuando usas modos incrementales.

Recomendación práctica para la mayoría de hosts de producción: flush = INCREMENTAL_ASYNC y un freq moderado (por ejemplo, 50–200). Esto reduce el problema de “pequeños syncs de escritura todo el día”.

Lo que intercambias: una ventana mayor de pérdida si el host se cae. Decide si eso es aceptable según la clase de host. Para endpoints endurecidos por cumplimiento, puede que te obliguen a flushing más estricto. Si haces eso, debes reducir el volumen de eventos aún más agresivamente.

Rotación de logs: hazlo aburrido

Los logs de auditoría rotan diferente que los logs generales; no dejes que logrotate te sorprenda. Usa las propias perillas de rotación de auditd:

• max_log_file y num_logs dimensionan la retención local.
• max_log_file_action = ROTATE suele ser correcto.
• max_log_file_action = KEEP_LOGS es cómo terminas con un disco lleno y una reflexión filosófica sobre incidentes.

Acciones por espacio en disco: decide cómo luce un fallo

Estos ajustes son política disfrazada:

• space_left_action, admin_space_left_action
• disk_full_action, disk_error_action

Para hosts de producción de propósito general, prefiero: alertar fuerte, mantener la caja en ejecución y preservar lo que se pueda. Para endpoints regulados, puede que tengas que suspender la auditoría o incluso detener el sistema. Si tu política es “detener en disco lleno”, más vale que tengas filesystems separados y monitorización que detecte el crecimiento antes del precipicio.

Backlog y tiempo de espera: absorber picos sin mentirte

El ajuste del backlog del kernel es para sobrevivir picos: actualizaciones de paquetes, jobs de CI, tormentas cron. Un backlog más grande puede ayudar—hasta que no, y entonces solo retrasaste la pérdida.

Usa tamaño de backlog para manejar ráfagas legítimas, pero trata el backlog persistente como “tus reglas son demasiado amplias” en lugar de “añade más buffer”. Los buffers no son throughput.

Postura práctica de Debian 13 sobre el modo inmutable

El modo inmutable (reglas bloqueadas hasta el reboot) es útil para evitar que un atacante desactive la auditoría tras conseguir root. También es útil para evitar que tú arregles un mal despliegue rápidamente.

Mi opinión: usa el modo inmutable solo en hosts donde tienes:

• conjuntos de reglas probados bajo carga realista,
• un rollback ensayado que incluya reboot,
• propiedad clara de “audit rompió prod”.

Realidades de almacenamiento y sistemas de archivos: ext4, XFS, ZFS, NVMe

El logging de auditoría es una carga de escrituras pequeñas. En almacenamiento moderno, las escrituras pequeñas no son automáticamente malas—hasta que las conviertes en un flujo constante con churn de metadatos y flushes forzados.

Separa el radio de explosión

Si solo puedes hacer un cambio de almacenamiento: pon /var/log o al menos /var/log/audit en su propio filesystem con un tamaño y monitorización sensatos. Esto hace tres cosas:

• evita que el crecimiento de audit llene root y deje la máquina inutilizable,
• reduce la contención de IO con datos de aplicación,
• te permite aplicar tuning de sistema de archivos/mount sin tocar todo lo demás.

ext4: bien, aburrido, predecible

ext4 en NVMe suele ser adecuado si evitas ajustes patológicos. Usa relatime. No montes con sync. No pongas tu log de auditoría en el mismo filesystem que una base de datos ocupada a menos que disfrutes juegos de culpas.

XFS: fuerte bajo concurrencia, pero no mágico

XFS maneja bien cargas paralelas, pero los logs de auditoría son mayormente escrituras de append. Si tu problema es volumen de eventos, XFS no te salvará. Si tu problema es contención y comportamiento de metadatos, puede ayudar. Mide; no vibes-checkees.

ZFS: buena herramienta, modos de fallo diferentes

Si escribes logs de auditoría en ZFS, los perillas cambian. ZFS puede convertir muchas escrituras pequeñas en patrones de IO distintos según recordsize, opciones sync y comportamiento del SLOG. Puede ser excelente, pero también es fácil convertir “pequeños appends” en “muchas transacciones síncronas”.

Postura práctica: si no estás ya ejecutando ZFS con madurez operativa, no lo introduzcas solo para “arreglar auditd”. Arregla primero el volumen de reglas.

Resistencia de NVMe SSD: no frágil, no infinita

Los SSD modernos de empresa resisten bastante, pero la resistencia sigue siendo un presupuesto. Lo que te mata son escrituras sostenidas e innecesarias. Audit a menudo es sostenido e innecesario cuando está mal configurado. Usa contadores SMART para probar tu caso ante stakeholders.

Envío, agregación y cómo mantener los logs de auditoría útiles

Los logs locales de auditoría son necesarios, no suficientes. En incidentes reales, el host comprometido es el lugar menos confiable para almacenar la verdad.

Local primero, remoto siempre (pero no te dupliques en escrituras)

Muchos entornos envían logs de auditoría a un SIEM mediante un agente que hace tail de /var/log/audit/audit.log. Eso es normal. Atención a dos problemas:

• Amplificación de IO inducida por tail: Algunos agentes se comportan mal en rotaciones o hacen fsyncs frecuentes. Prueba tu shipper.
• Explosiones de parsing: Si tu pipeline SIEM se atasca, Seguridad puede pedir “todo crudo” local para siempre. Plantéate y empuja hacia atrás. Define retención y demuestra que el pipeline remoto funciona.

Haz que claves y metadatos del host sean primordiales

Si no marcas reglas con claves y anotas eventos en el pipeline con rol del host, entorno y propietario, acabarás con un lago global de ruido idéntico. Así es como “auditar” se vuelve “almacenamiento caro con vibes”.

Política de retención: no acumules localmente

La retención local sirve para:

• respuesta a incidentes a corto plazo cuando el logging central se retrasa,
• buffer contra caídas de red,
• continuidad forense básica.

No es para archivo de varios meses a menos que tengas un requisito específico y un plan de almacenamiento. Ajusta max_log_file y num_logs según tasas medidas de eventos y una ventana de caída realista para tu pipeline de logs.

Tres mini-historias corporativas desde el campo

Incidente por una suposición errónea: “las escrituras de audit son solo logs, se comprimirán bien”

En una empresa mediana con mezcla de Debian y Ubuntu, Seguridad desplegó un “baseline estándar de auditoría Linux” durante un trimestre ya estresante. El baseline incluía auditoría por syscalls para un gran conjunto de operaciones de archivos, porque la plantilla había sido escrita para una flota mucho más pequeña y carga mucho más tranquila.

Operaciones asumió que se comportaría como logging de texto regular: “Son logs, serán escrituras secuenciales; compresión y rotación lo solucionarán”. Esa suposición murió rápido en hosts de CI. Esos hosts ya estaban calientes con pulls de contenedores, desempaquetado de capas y escritura de caches. Las nuevas reglas de auditoría essentially registraron un alto porcentaje de ese churn.

El primer síntoma no fueron errores de audit. Fueron timeouts en build y aumentos repentinos en IO wait. Servicios sensibles a latencia co-localizados empezaron a reportar ralentizaciones “aleatorias”. Luego la real: algunos hosts comenzaron a perder eventos de auditoría porque el backlog se llenó durante oleadas máximas de builds.

La solución no fue heroica. Eliminaron reglas amplias de syscalls de archivo, conservaron watches dirigidos sobre archivos de identidad y persistencia, y restringieron la auditoría de exec privilegiado a usuarios reales mediante restricciones de auid. También movieron /var/log/audit a un filesystem separado en hosts críticos. Cumplimiento quedó satisfecho porque las preguntas “quién cambió identidad y privilegio” volvieron a poder responderse, y la flota dejó de triturarse.

Una optimización que salió mal: “haz audit durable, pon flush a SYNC”

Un equipo de servicios financieros quería garantías más fuertes: “Nunca perder eventos de auditoría”. Alguien ajustó auditd.conf para máxima durabilidad. Pusieron flush = SYNC y endurecieron acciones por espacio para que el sistema suspendiera cuando el almacenamiento escaseara.

En papel, suena responsable. En la práctica, transformó trabajo administrativo rutinario en picos de latencia. Cada ráfaga de eventos auditados se tradujo en presión de escritura sincrónica. Durante ventanas de parcheo, los gestores de paquetes generaban tormentas densas de eventos (execs, escrituras de config). La latencia de almacenamiento subió. La ventana de parcheo se alargó. La gente reintentó. La tormenta de reintentos lo empeoró.

El contragolpe: un problema en el pipeline de logs demoró el envío fuera del host. Los logs locales crecieron más rápido de lo esperado. El filesystem dedicado de logs se llenó antes de lo previsto. El sistema suspendió la auditoría justo cuando más importaba—durante un evento operativo caótico—por las acciones estrictas de espacio. No perdieron la máquina, pero sí la traza de auditoría del período que los auditores necesitaban.

La configuración final fue menos “pura” y más fiable: flush incremental async, una ventana local de retención cuidadosamente dimensionada, monitorización de la utilización del filesystem de logs y una política acordada sobre qué pasa bajo presión de disco. “Nunca perder eventos” se convirtió en “no perder eventos en operación normal; bajo agotamiento de recursos, preservar el sistema y alertar inmediatamente”. No fue tan satisfactorio como una garantía dura, pero funcionó.

Una práctica aburrida pero correcta que salvó el día: claves, reglas mínimas y un ensayo

Un equipo de SaaS en salud había aprendido la lección, así que hizo algo poco glamoroso: escribieron un conjunto de reglas de auditoría con scope estricto, asignaron claves a cada regla y lo pusieron en gestión de configuración con revisión por pares. Cada regla tenía en el commit un “pregunta de incidente” adjunta: “Detectar cambios de config SSH”, “Detectar rutas de escalada de privilegio”, “Detectar persistencia vía cron”.

Además ensayaron. Trimestralmente hacían un ejercicio de mesa: simular una cuenta admin comprometida, modificar un drop-in de systemd, añadir un cron, y cambiar config de SSH. Luego verificaban que podían recuperar esos eventos con ausearch rápidamente, sin conocimiento tribal.

Cuando llegó un incidente real—credenciales de un ingeniero se filtraron y se usaron para modificar un include de sudoers—la respuesta fue aburrida en el mejor sentido. El on-call extrajo el resumen de la clave priv-esc, sacó la ventana exacta del cambio y confirmó la cuenta actor vía auid. Revirtieron, rotaron credenciales y tuvieron una traza de auditoría que fue fácil de explicar a liderazgo.

Nadie celebró el conjunto de reglas de auditoría. No tenía dashboard. No “se integró con IA”. Simplemente funcionó, y no destruyó discos en el proceso.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: IOPS de escritura en disco se disparan justo después de habilitar auditd

Causa raíz: Reglas de syscalls amplias (a menudo open/openat o watches de directorios en rutas calientes) creando volumen masivo de eventos.

Solución: Elimina syscalls amplias de acceso a archivos; reemplázalas por watches -w dirigidos en archivos críticos y reglas de execve privilegiadas filtradas por auid y euid. Usa claves para identificar los mayores culpables.

2) Síntoma: el contador lost aumenta; journald muestra “backlog limit exceeded”

Causa raíz: La producción de eventos de auditoría excede el consumo; auditd no puede drenar lo suficientemente rápido; el backlog se desborda.

Solución: Primero reduce la tasa de eventos (acotar reglas). Segundo aumenta backlog_limit para ráfagas. Tercero revisa contención de CPU y latencia de IO; si la escritura de auditd está bloqueada, puede desencadenar overflow de backlog.

3) Síntoma: latencia del host sube durante parcheo o jobs de CI

Causa raíz: Auditoría de exec privilegiado o cambios de archivos de forma amplia; gestores de paquetes y herramientas de build disparan ráfagas. A menudo combinado con flush = SYNC.

Solución: Mantén auditoría de exec privilegiado pero con scope (solo usuarios reales). Usa INCREMENTAL_ASYNC para flush. Considera excluir cuentas de automatización conocidas si la política lo permite.

4) Síntoma: el filesystem root se llena, el sistema se vuelve inestable

Causa raíz: Logs de auditoría en FS root, KEEP_LOGS, o rotación mal dimensionada al ritmo real de eventos. A veces envío remoto caído + retención local demasiado grande.

Solución: Pon /var/log/audit en un filesystem dedicado. Usa ROTATE. Ajusta retención según tasa medida de eventos y una ventana de caída realista. Monitoriza utilización.

5) Síntoma: no puedes cambiar reglas durante un incidente

Causa raíz: Modo inmutable habilitado al arranque (-e 2), a veces sin plan operativo.

Solución: No habilites modo inmutable hasta que las reglas hayan sido validadas bajo carga de producción y el rollback esté ensayado. Si ya está habilitado, tu única opción real es reiniciar con reglas corregidas.

6) Síntoma: logs de auditoría son masivos, pero aún no puedes responder “quién cambió X?”

Causa raíz: Sin claves, reglas sin foco y la creencia de que volumen equivale a visibilidad.

Solución: Reescribe reglas alrededor de preguntas de incidente. Usa claves. Prueba haciendo algunos cambios controlados y verifica la recuperación con ausearch/aureport.

7) Síntoma: IO alto incluso cuando el sistema está “idle”

Causa raíz: Vigilar directorios con alto churn como /var/log, /tmp o almacenamiento overlay de contenedores. “Idle” es una mentira; agentes en background generan churn.

Solución: Elimina watches de directorios y audita archivos críticos específicos en su lugar. Si necesitas auditoría de contenedores, usa telemetría específica del runtime, no watches de rutas globales.

Listas de verificación / plan paso a paso

Plan A: habilitas auditd en Debian 13 por primera vez

1. Define preguntas de incidente. Ejemplos: “¿Quién cambió sudoers?”, “¿Quién modificó la config de SSH?”, “¿Qué humano ejecutó comandos como root?”
2. Comienza con un conjunto mínimo de reglas. Watches para identidad/auth/persistencia; exec privilegiado filtrado por auid.
3. Etiqueta todo con claves. Estás construyendo una interfaz de diagnóstico, no solo un archivo de log.
4. Configura flush = INCREMENTAL_ASYNC y elige freq. Empieza en 50; ajusta según tasa de eventos y ventana de pérdida aceptable.
5. Separa /var/log/audit si el host es ocupado o crítico. Mantén el radio de explosión pequeño.
6. Configura rotación sensata. max_log_file_action = ROTATE, tamaños medidos, retención alineada con el envío.
7. Asegura que no se carguen duplicados o archivos legacy.
8. Prueba bajo carga real. Observa lost, backlog, latencia de IO y latencia p99 de servicios.
9. Decide la política de fallo. Ante disco lleno o fallo de auditoría: alertar, suspender o detener? Ponlo por escrito.
10. Solo entonces considera modo inmutable. Si no puedes reiniciar rápido, no te bloquees para arreglos.

Plan B: auditd ya está desplegado y los discos están gritando

1. Confirma pérdida de eventos/comportamiento del backlog. Si pierdes eventos, ya estás fallando en el propósito principal.
2. Encuentra las claves y reglas más calientes. Usa aureport --key y auditctl -l.
3. Elimina los foot-guns obvios. Watches de directorios en rutas de alto churn, reglas amplias de open/openat.
4. Cambia a flush incremental async si es seguro. Si la política lo prohíbe, debes reducir el volumen con más fuerza.
5. Mueve logs de auditoría a un filesystem dedicado. Hazlo en ventana de mantenimiento si es necesario. Esto reduce riesgo.
6. Vuelve a medir. IO, backlog, eventos perdidos y tu capacidad para responder preguntas clave de incidentes.

Preguntas frecuentes

1) ¿Hará flush = INCREMENTAL_ASYNC que los logs de auditoría sean “inseguros”?

Aumenta la ventana de eventos que podrían perderse en una caída súbita. Para la mayoría de sistemas de producción, ese intercambio es aceptable si mantienes el volumen de eventos bajo control y envías logs fuera del host rápidamente.

2) ¿Debería auditar cada execve en el sistema?

No. Audita execve privilegiados (euid=0) iniciados por usuarios reales (auid≥1000). Eso captura la mayoría de actividad de escalada significativa sin ahogarte.

3) ¿Por qué vigilar un directorio es mucho peor que vigilar un archivo?

Los directorios con churn generan un flujo constante de creaciones/renombres/cambios de atributos. En directorios de logs o temporales, ese churn es constante. Vigilar un puñado de archivos específicos ofrece señal alta con bajo volumen.

4) ¿Puedo confiar solo en journald en lugar de auditd?

No para semánticas de auditoría del kernel. Journald es genial para logs de servicios. Auditd provee captura estructurada de eventos de seguridad desde el subsistema de auditoría del kernel con garantías y campos distintos.

5) ¿Cuál es la prueba más rápida de que mi conjunto de reglas es útil?

Realiza un cambio controlado: edita /etc/ssh/sshd_config, ejecuta visudo o modifica un archivo en /etc/sudoers.d, luego recupera eventos con ausearch -k ssh-config y ausearch -k priv-esc.

6) ¿Mover /var/log/audit a su propio filesystem realmente mejora rendimiento?

A veces. La mayor ganancia es el aislamiento: evitas que las escrituras de audit compitan con IO de aplicaciones y reduces el riesgo de llenar root. La mejora de rendimiento depende de tu pila de almacenamiento.

7) ¿Qué tan grande debe ser backlog_limit?

Suficientemente grande para absorber picos sin perder, lo bastante pequeño para que notes la sobrecarga sostenida. Empieza con unos pocos miles a decenas de miles según tasa de eventos y memoria, luego mide el comportamiento del backlog durante trabajos pico.

8) ¿Debería habilitar modo inmutable en todos los servidores?

No. Úsalo selectivamente donde el coste operativo de “debes reiniciar para cambiar reglas” sea aceptable y esté ensayado. De lo contrario convierte malas configuraciones en outages prolongados.

9) Necesitamos “todo” para cumplimiento. ¿Qué le digo a los auditores?

Define “todo” como “todo relevante para controles de seguridad”. Proporciona evidencia: reglas mapeadas a controles (cambios de identidad, escalada de privilegios, persistencia), pérdida de eventos monitorizada y logs enviados fuera del host con retención.

10) ¿Por qué veo múltiples registros (SYSCALL, PATH, CWD) por acción?

Los eventos de auditoría están compuestos por múltiples registros que describen contexto de syscall, directorio de trabajo y rutas de archivos. Eso es normal—y por eso el volumen de eventos crece rápido cuando auditas syscalls frecuentes.

Conclusión: próximos pasos que puedes ejecutar hoy

Si tu despliegue de auditd en Debian 13 está dañando discos, no empieces ajustando números mágicos. Comienza por reducir la manguera de eventos. Elimina watches de directorios con churn. Deja de auditar syscalls amplios de acceso a archivos a menos que tengas un objetivo estrecho y un presupuesto medido para ello. Conserva las reglas que responden preguntas reales de incidentes y etiquétalas con claves para poder probarlo.

Luego haz que la persistencia sea menos dolorosa: flush incremental async, rotación sensata, filesystem dedicado para logs de auditoría y una política clara sobre qué ocurre cuando se agotan recursos. Finalmente, ensaya: realiza un pequeño cambio en un archivo sensible y confirma que puedes recuperar la traza de auditoría rápido. Eso es lo que significa “auditoría sensata”: útil bajo presión y sin intentar asesinar tu almacenamiento.