auditd: detectar cambios sospechosos en tu servidor Linux 2026

En 2023 me llegó un mail del CERT local avisando de una CVE crítica en OpenSSH. Parchear era trivial — dos minutos cambiando una versión en el gestor de paquetes. La pregunta importante llegó después: si mi servidor estuvo expuesto 48 horas hasta que actualicé, ¿alguien ya entró antes de que parcheara? ¿Dejó un backdoor, modificó un binario de sistema, creó un usuario nuevo, montó un cron que sobrevive al reinicio? Sin una fuente de verdad sobre quién hizo qué en ese servidor, no tengo cómo responder.

auditd es el sistema de auditoría nativo del kernel Linux: registra llamadas al sistema (syscalls), cambios en ficheros críticos, intentos de autenticación, y todo lo que esté definido en las reglas. No es glamoroso — sus logs son verbosos — pero es la Única forma de reconstruir qué pasó en un servidor después de un incidente. Esta guía recorre desde la instalación en Debian/Ubuntu/RHEL hasta reglas prácticas para detectar los movimientos que importan cuando algo sale mal.

---

Te llega un mail del CERT de tu país avisando que un grupo de atacantes está explotando una vulnerabilidad en OpenSSH. Parchear lleva dos minutos. Pero la pregunta importante es: ¿alguien ya entró antes de que parchearas? Si tu server estuvo expuesto 48 horas hasta que lo actualizaste, ¿cómo sabes si alguien dejó un backdoor, modificó un binario, o creó un usuario nuevo? Ahí entra auditd: el sistema de auditoría nativo del kernel Linux que te permite registrar quién hizo qué, cuándo, y desde dónde.

---

Índice

1. [Qué es auditd y por qué lo necesitas](#qué-es-auditd-y-por-qué-lo-necesitas)
2. [Instalación y primer arranque](#instalación-y-primer-arranque)
3. [Reglas para detectar cambios sospechosos](#reglas-para-detectar-cambios-sospechosos)
4. [Monitoreo y alertas en tiempo real](#monitoreo-y-alertas-en-tiempo-real)
5. [Reportes y análisis post-mortem](#reportes-y-análisis-post-mortem)
6. [Troubleshooting común](#troubleshooting-común)
7. [Conclusión](#conclusión)

---

Qué es auditd y por qué lo necesitas

auditd es el daemon de userspace que captura los eventos que el kernel audit subsystem genera. No es un antivirus ni un IDS de red (eso es responsabilidad de OSSEC, Wazuh, Snort, Suricata). Lo que hace auditd es específicamente auditar el comportamiento dentro del sistema: cambios de archivos, llamadas a syscalls críticas, intentos de login, modificaciones a configs, ejecución de binarios específicos.

Para entender por qué importa, pensá en el escenario típico de un incidente. Tu server fue comprometido entre el 1 y el 10 de agosto. Cuando te enterás, ya pasaron semanas. ¿Cómo reconstruís qué pasó?

• Los logs de aplicación (auth.log, nginx access.log, mysql slow.log) son fáciles de borrar para un atacante con acceso root.
• Los logs del sistema (syslog, journald) también.
• auditd es distinto: el daemon puede configurarse para escribir logs en un servidor remoto (auditd remote logging) o para que los eventos sean inmutables (audit.log en modo append-only). Un atacante con root puede parar el daemon, pero los eventos que ya se emitieron quedan.

Lo que sigue es entender la anatomía de las reglas de auditd. Una regla tiene tres partes:

• Watch: qué observar (un archivo, un directorio, una syscall).
• Permissions filter: qué operaciones cuentan (read, write, execute, attribute change).
• Key: una etiqueta que tú eliges para agrupar eventos en los reportes.

Por ejemplo: -w /etc/passwd -p wa -k identity le dice a auditd “monitoreá cambios y atributos al archivo /etc/passwd, etiquetá los eventos con la clave ‘identity'”. Después en los logs puedes filtrar todos los eventos con esa clave y ver quién modificó usuarios del sistema.

Antes de instalar, confirmá que tu kernel soporta auditoría. Casi todos los kernels modernos lo hacen, pero si estás en un container LXC/Docker estricto, el kernel del host puede no exponer el subsistema de auditoría. La forma rápida de saberlo es verificar si el filesystem /sys/kernel/security/ está montado con soporte:

# El comando auditctl viene con auditd; si no está, no hay soporte
which auditctl
# verifica el kernel
uname -r
# Si es 4.x+ casi seguro tienes audit subsystem
# verifica la config del kernel
zgrep CONFIG_AUDIT /proc/config.gz
# CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL=y
# CONFIG_AUDIT_TREE=y

Si auditctl no existe o CONFIG_AUDIT no está habilitado: tu kernel fue compilado sin el subsystem de auditoría. En la mayoría de las distros esto no pasa (todas lo incluyen), pero algunas imágenes minimalistas (especialmente containers) lo sacan. Solución: usa un kernel standard de tu distro.

Si estás en Docker: auditd en el container no funciona porque el container no tiene acceso al audit subsystem del host. Para auditar containers correctamente, auditd tiene que correr en el host y los eventos se asocian al container via cgroup. Esto requiere configuración extra (--privileged o capabilities específicas) y está fuera del alcance de esta guía introductoria.

---

Instalación y primer arranque

La instalación es directa en todas las distros. El paquete auditd trae el daemon, las herramientas (auditctl, ausearch, aureport), y reglas de ejemplo.

# Ubuntu/Debian
sudo apt update && sudo apt install auditd audispd-plugins
# RHEL/Fedora
sudo dnf install audit
# Arch
sudo pacman -S audit
# Alpine (común en containers)
sudo apk add audit

audispd-plugins es el dispatcher que te permite enviar eventos a syslog, remote syslog, o un SIEM. Si quieres enviar los logs de auditoría a un servidor central (recomendado para entornos serios), necesitas este paquete.

activa el servicio para que arranque en cada boot y arrancá ahora. No te saltes el enable: si auditd no arranca en el boot, el server está sin auditoría desde el primer minuto hasta que tú lo levantes a mano. En servers que ya están en producción, agregá esto al runbook de reinicios:

sudo systemctl enable auditd
sudo systemctl start auditd
sudo systemctl status auditd
# active (running)

systemctl status auditd tiene que mostrar active (running). Si muestra active (exited), el daemon arrancó y se cerró inmediatamente — eso casi siempre significa error de configuración. journalctl -xeu auditd te muestra el error.

Confirmá que está operativo. auditctl -l lista las reglas cargadas actualmente. Si acabás de instalar, vas a ver reglas default que trae el paquete (audit de cambios a /etc/passwd, /etc/shadow, llamadas a sudo, etc.). Si la lista está vacía, las reglas default no se cargaron:

sudo auditctl -l
# -w /etc/passwd -p wa -k identity
# -w /etc/shadow -p wa -k identity
# -w /etc/sudoers -p wa -k privileged
# ...

Si -l no devuelve reglas: o las reglas default están deshabilitadas, o tu /etc/audit/audit.rules está vacío. En RHEL/Fedora, las reglas default están en /usr/share/audit/sample-rules/. En Debian/Ubuntu, en /usr/share/doc/auditd/examples/. Copialas a /etc/audit/rules.d/ o agregalas a /etc/audit/audit.rules.

verifica que los logs se están generando. Cada acción auditada debería dejar un evento en /var/log/audit/audit.log. La mejor forma de probar es disparar una acción que tú sepas que está auditada (como cambiar el dueño de un archivo) y ver si aparece:

# Listar algo
ls -la /etc/passwd
# Ver los eventos generados
sudo ausearch -ts recent
# Si ves eventos del comando ls, está funcionando

-ts recent (timestamp, recent) filtra por eventos de los últimos 10 minutos. Si ves entradas tipo type=SYSCALL ... uid=0 ... exe="/usr/bin/ls", el sistema está auditando.

Si ausearch no devuelve nada después de tocar archivos auditados: o las reglas no están cargadas (auditctl -l), o el daemon no está corriendo (systemctl status auditd), o el log está en otra ubicación. sudo grep -i '^log_file' /etc/audit/auditd.conf te dice dónde se está escribiendo.

---

Reglas para detectar cambios sospechosos

Las reglas default cubren lo básico, pero si quieres detectar actividad sospechosa real, necesitas reglas custom. Acá van las más importantes, agrupadas por categoría de amenaza.

Regla 1: cambios a archivos críticos del sistema. Estos archivos no deberían cambiar nunca en un server en producción. Si cambian, es señal de compromiso, de un sysadmin despistado, o de un update legítimo que tienes que verificar.

sudo nano /etc/audit/rules.d/10-critical-files.rules

# Archivos de identidad y autenticación
-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
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
# Configuración SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config
# PAM (autenticación)
-w /etc/pam.d/ -p wa -k pam
# Binarios de sistema (cambios aquí = rootkit probable)
-w /usr/bin/ -p wa -k system_binaries
-w /usr/sbin/ -p wa -k system_binaries
-w /usr/lib/ -p wa -k system_libraries
-w /usr/lib64/ -p wa -k system_libraries
-w /bin/ -p wa -k system_binaries
-w /sbin/ -p wa -k system_binaries

-w define un watch sobre un path (archivo o directorio). -p wa significa “permissions: write and attribute change” — captura escrituras al archivo y cambios de permisos/owner/timestamp. Sin -p wa no audita nada, solo configura el watch. Con -p wa se vuelve ruidoso: cualquier chmod, chown, touch al archivo genera evento. Para archivos críticos eso es lo que quieres.

-k identity es la clave que usas para filtrar después con ausearch -k identity. Elegí nombres descriptivos por categoría: identity, sshd_config, sudoers, pam, system_binaries.

Sobre auditar /usr/bin/: genera mucho ruido. Cada actualización de paquete toca cientos de binarios ahí. Si auditás eso, después de apt upgrade tienes 2000 eventos. Útil para detectar un atacante reemplazando binarios (lo cual es señal clarísima de compromiso), pero llenísimo de falsos positivos de updates legítimos. Solución: filtrá en tus alertas para que /usr/bin/ solo dispare alertas cuando el evento viene de procesos sospechosos o en horarios raros, no del package manager.

Recargá las reglas sin reiniciar el daemon. Importante: auditctl -R lee el archivo de reglas y las aplica, pero no persiste entre reinicios. Las reglas persistentes van en /etc/audit/rules.d/ (lo que ya hicimos arriba). El daemon las lee al arrancar desde /etc/audit/audit.rules, que normalmente es autogenerado por augenrules desde /etc/audit/rules.d/:

sudo augenrules --load
sudo auditctl -l | head
# verifica que las reglas nuevas aparecen

augenrules es el comando que compila todas las reglas de /etc/audit/rules.d/*.rules en un único /etc/audit/audit.rules. Si no corres augenrules, las reglas en /etc/audit/rules.d/ no se aplican al reinicio. Si augenrules --load falla con error de sintaxis: una de las reglas en rules.d/ tiene un typo. El error te dice qué archivo y qué línea.

Regla 2: cambios a configuración de red. Similar al anterior pero enfocado en configs que afectan la red:

sudo nano /etc/audit/rules.d/20-network.rules

# Firewall
-w /etc/ufw/ -p wa -k firewall_config
-w /etc/firewalld/ -p wa -k firewall_config
-w /etc/iptables/ -p wa -k firewall_config
-w /etc/nftables.conf -p wa -k firewall_config
# Resolución DNS
-w /etc/hosts -p wa -k dns_config
-w /etc/resolv.conf -p wa -k dns_config
-w /etc/nsswitch.conf -p wa -k dns_config
# Interfaces de red
-w /etc/network/ -p wa -k network_config
-w /etc/NetworkManager/ -p wa -k network_config
# Cron (tareas programadas)
-w /etc/crontab -p wa -k cron_config
-w /etc/cron.d/ -p wa -k cron_config
-w /etc/cron.daily/ -p wa -k cron_config
-w /var/spool/cron/ -p wa -k cron_config

Auditar cron es crítico. Una de las técnicas de persistencia post-exploit es agregar una tarea cron que se ejecute cada X minutos para mantener el acceso (reverse shell, beacon C2). Si auditas /etc/cron.d/, detectás inmediatamente cualquier agregado sospechoso.

Regla 3: ejecución de comandos privilegiados. Estas reglas disparan eventos cuando se ejecutan binarios que cambian el contexto de seguridad (su, sudo, newgrp):

sudo nano /etc/audit/rules.d/30-privileged.rules

# Ejecución de su (cambio de usuario)
-a always,exit -F path=/usr/bin/su -F perm=x -k privileged
# Ejecución de sudo
-a always,exit -F path=/usr/bin/sudo -F perm=x -k privileged
# newgrp (cambio de grupo)
-a always,exit -F path=/usr/bin/newgrp -F perm=x -k privileged
# Cambios al setuid/setgid de binarios (escalada de privilegios)
-a always,exit -F perm=a -F auid>=1000 -F auid!=-1 -k perm_mod

-a always,exit significa “agregá esta regla al syscall exit filter, siempre” (a diferencia de never, que excluye). -F path= filtra por ejecutable. -F perm=x filtra por syscall de execve. -F auid>=1000 -F auid!=-1 filtra por UID del usuario que originó la sesión (auid), descartando root y servicios del sistema — solo audita cuándo un usuario regular ejecuta el binario.

Sobre perm_mod (cambios de permisos): la regla auid>=1000 filtra para que solo se registren cambios de permisos hechos por usuarios regulares, no por el package manager o root scripts. Esto reduce el ruido de updates y mantiene la señal.

Recargá todo. Después de armar las tres secciones de reglas, aplicá y verifica:

sudo augenrules --load
sudo auditctl -l | wc -l
# Debería ser 30+ líneas

Si el contador de reglas se queda en 0 o no cambia: las reglas no se cargaron. verifica con sudo auditctl -R /etc/audit/audit.rules (carga manual). Si eso funciona pero augenrules no, hay un problema con la generación del archivo consolidado. ls -la /etc/audit/audit.rules te dice si existe y cuándo se modificó por última vez.

Si tu server se vuelve lento después de cargar reglas: auditd puede impactar performance, especialmente si auditás syscalls de alta frecuencia. verifica con top (proceso auditd) y iostat. Si está consumiendo mucho CPU, estás auditando demasiado — empeza con reglas sobre archivos críticos solamente y expandí gradualmente. La regla más cara en performance es cualquier cosa con -S all (audita todas las syscalls).

---

Monitoreo y alertas en tiempo real

Tener reglas cargadas no sirve si no las mirás. auditd tiene herramientas para alertas en tiempo real y para alertas asíncronas.

Monitoreo activo con ausearch. El comando más útil es buscar eventos por clave y rango de tiempo:

# Eventos de las últimas 24 horas con clave "identity"
sudo ausearch -k identity -ts today
# Eventos de los últimos 10 minutos en el archivo audit.log
sudo ausearch -ts recent -f /etc/passwd
# Eventos de un usuario específico
sudo ausearch -ua 1000 -ts today
# Eventos de un proceso específico
sudo ausearch -p 1234
# Eventos fallidos (algo se intentó pero falló)
sudo ausearch -m USER_LOGIN -sv no -ts today

-ts today es el flag que define el rango temporal. today, yesterday, this-week, this-month, recent (últimos 10 minutos), o un timestamp específico (-ts 08/12/2026). Sin -ts, devuelve todo desde el inicio del log — que en servers con mucho movimiento puede ser muchísimo.

Alertas en tiempo real con auditd + email. La forma más directa es configurar un action plugin que mande mail cuando se dispara una regla específica. Esto va en /etc/audit/plugins.d/:

sudo nano /etc/audit/plugins.d/mail.conf

active = yes
direction = out
path = /sbin/audisp-remote
type = always

Para alertas por mail específicas por regla, lo más simple es usar un script wrapper que lea audit.log y mande email cuando matchee una clave. Este va como un cron job corriendo cada minuto:

sudo nano /usr/local/bin/audit-alerts.sh

#!/bin/bash
# Revisa audit.log por eventos críticos y manda alerta
AUDIT_LOG=/var/log/audit/audit.log
LAST_CHECK_FILE=/var/lib/audit/last_check
# Marca de la última línea que procesamos
if [ -f "$LAST_CHECK_FILE" ]; then
    LAST=$(cat $LAST_CHECK_FILE)
else
    LAST=0
fi
# Buscar eventos con claves críticas desde la última marca
NEW_EVENTS=$(ausearch -k identity,sshd_config,firewall_config,cron_config -ts $(date -d "1 minute ago" +%m/%d/%Y %H:%M:%S) 2>/dev/null)
if [ -n "$NEW_EVENTS" ]; then
    echo "$NEW_EVENTS" | mail -s "[ALERTA] Cambios críticos detectados en $(hostname)" [email protected]
fi
# Actualizar marca
wc -l $AUDIT_LOG | awk '{print $1}' > $LAST_CHECK_FILE

sudo chmod +x /usr/local/bin/audit-alerts.sh
echo "* * * * * root /usr/local/bin/audit-alerts.sh" | sudo tee /etc/cron.d/audit-alerts

Sobre este script: corre cada minuto, busca eventos con las claves críticas en el último minuto, y si encuentra algo manda un email. Es básico pero efectivo. Para producción seria, mandá las alertas a un SIEM (Wazuh, Splunk, ELK) o a Slack/Telegram vía webhook en vez de email — el email tarda minutos y es poco confiable bajo carga.

Si los emails no salen: 1) verifica que mail (comando) esté instalado — apt install mailutils en Debian/Ubuntu. 2) verifica que tengas un MTA configurado — dpkg -l | grep postfix. 3) prueba mandar un mail manual: echo "test" | mail -s test [email protected]. Si no llega, el problema es del MTA, no de auditd.

Logs remotos con audisp-remote. Esto es la pieza crítica para entornos serios: enviás los eventos de auditoría a un servidor central donde el atacante no tiene acceso. Si tu server se compromete, el atacante puede parar auditd localmente, pero los eventos ya enviados al servidor remoto persisten.

sudo nano /etc/audit/plugins.d/au-remote.conf

active = yes
direction = out
path = /sbin/audisp-remote
type = always

sudo nano /etc/audit/audisp-remote.conf

remote_server = siem.empresa.com
port = 60
transport = tcp
# O kerberos si tienes infra KDC
kerberos = no

sudo systemctl restart auditd

Sobre el puerto 60: por convención, audisp-remote usa TCP/60. El servidor central tiene que tener un listener en ese puerto (típicamente auditd en modo server con --listen). Si te equivocas de puerto o no abres el firewall, los logs se pierden silenciosamente — audisp-remote no retry agresivamente por default.

Si los logs no llegan al servidor remoto: 1) verifica que el puerto 60 está abierto en el servidor destino (nc -zv siem.empresa.com 60). 2) revisa el log local: journalctl -u auditd | grep audisp-remote. 3) verifica que SELinux no esté bloqueando: en RHEL con SELinux enforcing, setsebool -P auditd_remote_enable 1 lo permite.

---

Reportes y análisis post-mortem

Después de un incidente (o periódicamente como auditoría), aureport genera resúmenes legibles del log. Esto es lo primero que corres cuando te dicen “revisa si pasó algo raro en el server X entre el 1 y el 10 de agosto”.

Reportes básicos:

# Resumen general del log
sudo aureport
# Eventos de login
sudo aureport -au
# Cambios a archivos
sudo aureport -f
# Ejecución de comandos privilegiados
sudo aureport -x
# Cambios de cuenta
sudo aureport -m
# Eventos fallidos
sudo aureport --failed

aureport sin argumentos te da un resumen de todas las categorías: cuántos eventos totales, cuántos por tipo, top usuarios que generaron eventos, top comandos ejecutados. Es el primer comando para un análisis exploratorio.

Ejemplo de análisis post-incidente:

# Buscá todos los eventos del rango del incidente
sudo ausearch -ts 08/01/2026 -te 08/10/2026
# Filtrá por cambios a archivos críticos
sudo ausearch -k identity,sudoers -ts 08/01/2026 -te 08/10/2026
# Buscá logins exitosos en ese rango
sudo ausearch -m USER_LOGIN -sv yes -ts 08/01/2026 -te 08/10/2026
# Buscá cambios a cron (técnica común de persistencia)
sudo ausearch -k cron_config -ts 08/01/2026 -te 08/10/2026

Interpretación: si ves entradas como type=SYSCALL ... uid=0 ... exe="/usr/bin/useradd" con key="identity", eso es un atacante agregando un usuario nuevo. Si ves exe="/usr/bin/crontab" con key="cron_config", es una tarea programada nueva — potencialmente un beacon C2.

Convertir eventos a formato legible para humanos. ausearch por default devuelve formato raw (key=value). Para un humano es difícil de leer. usa --format text o --interpret:

sudo ausearch -k identity -ts today --interpret

--interpret traduce los IDs a nombres legibles: auid=1000 se muestra como auid=tu_usuario, exe=/usr/bin/sudo se mantiene legible, los códigos de syscall se expanden a sus nombres (execve en vez de 59).

Para un reporte bonito en HTML (útil para presentar a management o enviar como attachment):

sudo aureport -ts 08/01/2026 -te 08/10/2026 --summary -i > reporte_agosto.html

El archivo HTML generado es navegable, tiene tablas y se ve profesional. Compartilo con el equipo de seguridad o adjuntalo al ticket del incidente.

Si ausearch devuelve “no matches” pero estás seguro de que hubo eventos: el log rotó. Por default, /etc/audit/auditd.conf tiene max_log_file_action = ROTATE, así que cuando el log llega a cierto tamaño se renombra a audit.log.1, audit.log.2, etc. Si el evento que buscás está en audit.log.1, tienes que pasarle el archivo: AUDIT_LOG_FILE=/var/log/audit/audit.log.1 sudo ausearch -ts 08/01/2026.

---

Troubleshooting común

“Error sending audit event, error -28 (No space left on device)”

auditd no puede escribir al log porque el disco está lleno. Esto es crítico porque significa que dejás de auditar. Tres acciones:

# 1. verifica el espacio
df -h /var/log/audit/
# 2. Liberá espacio (logs viejos, paquetes huérfanos)
sudo journalctl --vacuum-size=100M
sudo apt autoremove
# 3. configura rotación más agresiva en /etc/audit/auditd.conf
max_log_file = 50
max_log_file_action = ROTATE
num_logs = 10

max_log_file = 50 son megabytes. Cuando el log llega a 50MB, se rota. num_logs = 10 mantiene 10 archivos rotados. Si cada uno es 50MB, total 500MB de espacio reservado para audit. Ajustá según tu volumen de eventos.

“audit: backlog limit exceeded”

El kernel está generando eventos más rápido de lo que auditd puede escribir al disco. Causas: disco lento, reglas excesivamente amplias (auditar todas las syscalls), o el server está bajo ataque con eventos de alta frecuencia.

# Subí el backlog en /etc/audit/rules.d/audit.rules (NO en auditd.conf)
-b 16384

El parámetro -b en audit.rules (NO backlog_limit en auditd.conf) controla el tamaño del buffer en el kernel. El default es 320. Subirlo a 16384 da más margen pero consume más memoria del kernel. Si sigues viendo “backlog exceeded” después de subirlo, el problema es que auditd no puede escribir lo suficientemente rápido — disco lento, considerar storage dedicado para auditoría.

auditd no arranca en el boot

El servicio está habilitado pero systemd no lo levanta. Causas comunes:

# 1. verifica el estado
sudo systemctl status auditd
# inactive (dead)
# 2. Logs del boot
sudo journalctl -u auditd -b
# 3. Causa típica: auditd intenta arrancar antes de que el filesystem esté listo
sudo systemctl edit auditd
# Agregá:
# [Unit]
# After=local-fs.target

Si las reglas custom desaparecen después de reiniciar: no corriste augenrules --load o las pusiste en el archivo equivocado. Las reglas tienen que estar en /etc/audit/rules.d/*.rules, y augenrules las compila a /etc/audit/audit.rules. Si editaste /etc/audit/audit.rules directamente, tus cambios se sobrescriben en el próximo augenrules.

Para debugging de reglas sin auditd real, auditctl -m te permite insertar un mensaje custom en el log:

sudo auditctl -m "Probando que auditd funciona"
sudo ausearch -m USER_TEST

Si ves el mensaje, auditd está escribiendo bien al log. Útil para distinguir entre “la regla no se dispara” y “auditd no está escribiendo”.

Si los logs de audit ocupan demasiado espacio y rotan muy rápido: estás auditando demasiado. Las reglas más ruidosas son las de syscalls (-S all), las de directorios grandes (/var/log, /tmp), y las de cambios de archivos en /usr/. Empezá con las reglas críticas que mostramos en este artículo y expandí gradualmente solo si necesitas.

---

Conclusión

auditd es la pieza fundamental de la auditoría de un server Linux. No es glamoroso, no es entretenido de configurar, pero es lo que distingue “creo que no pasó nada” de “tengo evidencia de qué pasó exactamente”. Para el caso básico, las reglas default que trae el paquete + las reglas de archivos críticos que mostramos acá te cubren el 90% de los escenarios de detección. Para entornos serios, agregá envío remoto a un SIEM y monitoreo en tiempo real con alertas. Próximos pasos: revisa qué reglas cargás y cuáles realmente disparan eventos (a veces auditás cosas que nunca pasan y pensás que estás cubierto pero no), configura augenrules y verifica que las reglas persistan después de un reinicio, y considera integrar con un SIEM centralizado si administras más de tres servers.

Lee también: [Fail2ban para proteger SSH](/fail2ban-proteger-servidor-ssh-ataques-fuerza-bruta/) para una capa adicional de detección, o [Hardening SSH: 7 cambios de seguridad](/hardening-ssh-7-cambios-seguridad/) para reducir la superficie de ataque antes de configurar auditoría.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux