Linux Auditd: cómo registrar correctamente los eventos de seguridad

Linux Auditd Registra los eventos relevantes para la seguridad directamente desde el núcleo y me proporciona un registro completo de los inicios de sesión, las modificaciones de archivos, la ejecución de comandos y las llamadas al sistema. Correcto Una vez configurado, detecto los ataques de forma temprana, cumplo con los requisitos de cumplimiento normativo, como la norma ISO 27001 o la norma PCI DSS, y analizo los incidentes de forma fiable desde el punto de vista forense.

Puntos centrales

Este Resumo la visión general de forma deliberadamente concisa, orientada a la práctica y sin frases hechas, para que comprendas de inmediato cómo definir las reglas de auditoría, proteger los registros y extraer conclusiones. I Enumera los componentes más importantes, los casos de uso típicos, las normas recomendables y las fuentes de error que, en muchos entornos, dan lugar a puntos ciegos. Así que Podrás ver de un vistazo qué ajustes de auditd.conf son los que cuentan y qué herramientas hay disponibles para el análisis. Posteriormente Profundizo en cada tema con ejemplos, recomendaciones claras y una tabla con los parámetros clave. De modo que lograrás pasar de „Auditd está en funcionamiento“ a „Auditd proporciona señales de seguridad útiles“.

• Registro de auditoría: trazabilidad completa de las acciones relevantes para la seguridad
• Reglas: archivos críticos específicos, execve, privilegios y configuraciones
• Protección de registros: Rotación, activación por memoria, reacción ante cuellos de botella
• Remoto: recopilación centralizada a través de TCP/TLS y conexión con SIEM
• Análisis: ausearch, aureport, claves claras y una documentación bien estructurada

Auditd de Linux en el plan de seguridad

Auditd Complementa los registros del sistema clásicos, ya que se centra específicamente en las acciones relevantes para la seguridad y registra los eventos a través de la interfaz del núcleo. El Por defecto, Daemon registra estos eventos en /var/log/audit/audit.log y registra qué usuario ha realizado qué acción y en qué momento. De este modo puedo comprobar rápidamente cualquier indicio sospechoso, como cambios no deseados en /etc/ssh/sshd_config o en archivos confidenciales como /etc/shadow. En En entornos regulados, esto me permite obtener pruebas de incumplimientos de las directrices y cumplir los requisitos de un registro fiable. Frente a A diferencia de los datos clásicos de los registros o de Syslog, Auditd ofrece una visión detallada y centrada en la seguridad, que resulta fundamental para el análisis de ataques.

Arquitectura: núcleo, daemon, herramientas

El El sistema de auditoría se divide en un subsistema del núcleo para el registro y el servicio del espacio de usuario auditd para el almacenamiento y las herramientas de gestión y análisis. Acerca de auditctl ¿Establezco reglas en tiempo de ejecución o cargo reglas persistentes al iniciar el sistema? /etc/audit/rules.d/*.rules. Con ausearch filtro los eventos por hora, usuario, clave o archivo, mientras que aureport genera informes concisos. Así que Combino un registro controlado de forma detallada con un análisis rápido y mantengo la trazabilidad de la pista de auditoría en todo momento. Importante es una nomenclatura coherente sobre -k Claves, para que las consultas posteriores funcionen correctamente.

Instalación y activación

En Instalo RHEL/CentOS auditoría a través de dnf install audit o yum install audit, en Debian/Ubuntu utilizo apt install auditd audispd-plugins. De acuerdo con Tras la instalación, inicio y activo el servicio con systemctl start auditd y systemctl enable auditd, compruebo el estado con systemctl status auditd. Tan pronto como Cuando el subsistema de auditoría y el servicio están en funcionamiento, los eventos se registran, de acuerdo con las reglas, en /var/log/audit/audit.log. I Comprueba que funciona correctamente accediendo específicamente a un archivo supervisado y, a continuación, busca el evento con ausearch -k keyname. Para Para garantizar un inicio coherente en cada arranque, me aseguro de que existan reglas persistentes y de que se carguen correctamente.

Inicio anticipado, cartera de proyectos pendientes y protección de las normas

A Para no perderme los primeros eventos del arranque, activo el subsistema de auditoría ya desde el inicio del núcleo. A este respecto Configuraré los parámetros del kernel y un tamaño de backlog suficiente para que no se pierdan eventos durante la fase de arranque. Además Una vez cargada, bloqueo la base de reglas para evitar que sea manipulada.

• Parámetros del núcleo: audit=1 audit_backlog_limit=8192 en /etc/default/grub añadir, y a continuación actualizar-grub (Debian/Ubuntu) o grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL/CentOS).
• Atrasos en las normas: En las reglas de inicio, establezco -b 8192, para dimensionar adecuadamente la cola del núcleo.
• Bloquear reglas: Una vez cargada la base de reglas definitiva, activo el modo «Immutable» con -e 2. A partir de ese momento, solo se podrán realizar cambios tras reiniciar el sistema, lo que supone una protección eficaz contra las manipulaciones en tiempo real.
• Comportamiento en caso de desbordamiento: En /etc/audit/auditd.conf defino overflow_action (por ejemplo SYSLOG o SINGLE), para que, cuando el búfer esté lleno, obtenga respuestas bien definidas.

Definir correctamente las normas de auditoría

El La calidad del registro de auditoría depende de unas normas claras y específicas que abarquen las acciones críticas y eviten el ruido innecesario. Para Los archivos confidenciales los guardo, por ejemplo, -w /etc/passwd -p warx -k passwd_changes y añade las reglas correspondientes para /etc/shadow, /etc/sudoers o /etc/ssh/. A Para registrar la ejecución de comandos, utilizo -a always,exit -F arch=b64 -S execve así como la versión de 32 bits, para que cada versión siga siendo visible, incluso a través de root. Para Los programas de servicio como Apache los filtro específicamente mediante la ruta del binario, por ejemplo: -a always,exit -F arch=b64 -S all -F exe=/usr/sbin/apache2 -k apache_activity. I Documenta cada regla con comentarios concisos y claves inequívocas, para que los análisis sean reproducibles y los compañeros y compañeras puedan comprender la intención.

Ejemplos avanzados de reglas y ajuste

Para Para profundizar más, creo un conjunto específico que pone de manifiesto los cambios de privilegios, las intervenciones en el núcleo, las modificaciones de tiempo y de red, así como los mecanismos persistentes, sin interferencias relacionadas con paquetes o copias de seguridad.

• Solo usuarios interactivos: -F auid >= 1000 -F auid != 4294967295 complementado con execve-Reglas para excluir los servicios del sistema.
• Cambio de privilegios: -a always,exit -F arch=b64 -S setuid,setreuid,setresuid -k priv_change y la versión de 32 bits. Opcional: -C uid!=euid, siempre que se admitan comparaciones de campos.
• Módulos del núcleo: -a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k kmod_change; además: -w /sbin/insmod -p x -k kmod_exec, -w /sbin/modprobe -p x -k kmod_exec.
• Cambios de horario: -a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_change y -w /etc/localtime -p wa -k time_change.
• Montajes y sistema de archivos: -a always,exit -F arch=b64 -S mount,umount2 -k fs_mount; -w /etc/fstab -p wa -k fs_mount.
• Base de red: -a always,exit -F arch=b64 -S sethostname,setdomainname -k net_conf; -w /etc/hosts -p wa -k net_conf, -w /etc/hostname -p wa -k net_conf, -w /etc/resolv.conf -p wa -k net_conf.
• Cron y temporizadores: -w /etc/crontab -p wa -k sched, -w /etc/cron.d/ -p wa -k sched, -w /var/spool/cron/ -p wa -k sched, -w /etc/systemd/system/ -p wa -k sched, -w /usr/lib/systemd/system/ -p wa -k sched.
• Persistencia a través de SSH: -w /root/.ssh/ -p wa -k ssh_keys, -w /home/ -p wa -k ssh_keys (senderillo estrecho en authorized_keys(se limita el número de archivos por usuario para evitar interferencias).
• Reducir el uso indebido de SUID y SGID: Centrarse en los directorios ejecutables: -w /usr/bin/ -p wa -k bin_change, -w /usr/sbin/ -p wa -k bin_change, -w /bin/ -p wa -k bin_change, -w /sbin/ -p wa -k bin_change.
• Registrar solo los fallos (para llamadas al sistema ruidosas): -a always,exit -F arch=b64 -S open,openat -F success=0 -k file_denied.
• Reducir el ruido: Excluir los gestores de paquetes y las copias de seguridad, por ejemplo,. -a never,exit -F exe=/usr/bin/dpkg, -a never,exit -F exe=/usr/bin/apt, -a never,exit -F exe=/usr/bin/yum, -a never,exit -F exe=/usr/bin/rpm, -a never,exit -F exe=/usr/bin/rsync (Comprueba la ruta en cada distribución).

Gestión de registros y protección contra la pérdida de registros

Sin Si la rotación no es adecuada y los umbrales no están bien definidos, los registros de auditoría corren el riesgo de perder datos valiosos o de saturar el sistema de archivos. En /etc/audit/auditd.conf Defino, entre otras cosas, max_log_file, max_log_file_action, num_logs, space_left y reacciones como space_left_action, disk_full_action o disk_error_action. I Prefiero acciones como ROTAR y una notificación temprana a Syslog, para que pueda reaccionar a tiempo en caso de atascos. Además Guardo los registros de auditoría en un servidor independiente para dificultar la manipulación del sistema afectado y conservar las pruebas. El La siguiente tabla clasifica los parámetros principales y muestra ajustes típicos y prácticos.

Parámetros	Propósito	Ejemplo	Nota
archivo_de_registro	Ubicación de almacenamiento de los registros de auditoría	/var/log/audit/audit.log	Mantener la ruta predeterminada y protegerla de forma clara
log_format	Formato de los eventos	RAW	El formato RAW facilita el análisis forense sin pérdida de información
max_log_file	Tamaño máximo del archivo (MB)	100 hasta 500	Ajustar el tamaño en función del volumen de eventos y del espacio de almacenamiento
max_log_file_action	Acción al alcanzar la altura	ROTAR	La rotación evita que se bloquee o se sobrescriba
num_logs	Número de archivos almacenados	5 hasta 10	Suficiente historial para realizar análisis, sin ocupar demasiado espacio de almacenamiento
space_left	Umbral de memoria libre (MB)	1024 o superior	Las alertas tempranas permiten reaccionar a tiempo
space_left_action	Reacción en caso de que el valor sea inferior al mínimo	SYSLOG	Considera además el envío de un correo electrónico o una alerta SIEM
disk_full_action	Qué hacer cuando el soporte de datos está lleno	SUSPENDER o ALTO	Una decisión clara en función de la aceptación del riesgo

Registro remoto y análisis centralizado

Para Para muchos servidores, utilizo el registro centralizado a través de TCP/TLS, controlado mediante parámetros como tcp_listen_port y los terminales correspondientes. Acerca de Mediante los complementos de audispd o rsyslog, envío eventos a una plataforma SIEM o de seguridad, y correlaciono los errores de inicio de sesión, los cambios de configuración y los inicios de procesos sospechosos. Así que Detecto patrones que, en un servidor aislado, pasan desapercibidos, pero que, cuando se dan en conjunto, activan inmediatamente una alarma. Quién quien ya utilice paneles de control, se beneficia de Agregación de registros en el alojamiento, ya que allí los eventos de auditoría se combinan con otros datos de telemetría. I Asegúrate, además, de que la ruta de transporte sea segura y de que exista una separación clara entre los sistemas productivos y la instancia de recopilación.

Análisis: cómo utilizar «ausearch» y «areport» de forma eficaz

Datos brutos no sirven de nada si no puedo filtrarlos rápidamente, así que empiezo con claves claras y utilizo ausearch para consultas específicas. Con ausearch -k passwd_changes -ts today ¿Debería tener en cuenta, por ejemplo, los cambios recientes en /etc/passwd ; Si es necesario, ajusto los intervalos de tiempo y los filtros de usuarios. Para Proporciona informes generales aureport --summary tablas concisas que muestran los inicios de sesión destacados, los cambios en los archivos y la frecuencia de las llamadas al sistema. Además Complemento la visión sobre el inicio de los procesos y el uso de los recursos con Contabilidad de procesos, para correlacionar las cadenas de ejecuciones y los picos de carga. En Lo que importa es que pueda responder a las preguntas en cuestión de segundos: quién, qué, cuándo, dónde y cómo.

Profundizar en el análisis: cómo interpretar correctamente los campos de eventos

De modo que Para que los análisis sean precisos, conozco los campos y los tipos de eventos más importantes. SYSCALL-Las entradas incluyen, entre otras cosas,. auid (UID de registro), uid/euid/suid (UID real/efectivo/guardado), ses (ID de sesión) y exe (archivo ejecutable). PATH-Los bloques muestran las rutas afectadas, EXECVE enumera los argumentos, CWD proporciona el directorio de trabajo. Con ausearch -m SYSCALL -sc execve -ua 1000 -ts recent Me centro en las presentaciones interactivas; aureport -x --summary -i Me permite ver de un vistazo las frecuencias y las anomalías. Importante: auid queda por encima de sudo o los saltos setuid son constantes y, por lo tanto, constituyen el criterio de filtrado más sólido para determinar „¿Quién lo ha iniciado?“.

Evite los errores típicos

A Las reglas demasiado amplias saturan los registros y ocultan las pistas realmente importantes, por lo que me centro en los archivos críticos, en «execve», en los cambios de privilegios y en las configuraciones relevantes para la seguridad. Falta Una rotación adecuada; si no, los sistemas se ven expuestos a riesgos, por lo que establezco límites claros en cuanto al tamaño, el número y las medidas a tomar en caso de cuellos de botella. I Supervisa también la configuración de auditoría y el directorio /var/log/audit/, porque los atacantes quieren borrar sus huellas. Y Documento cada regla indicando la clave, el objetivo y una breve justificación, para que los análisis sean coherentes. Quién Quien tenga problemas de rendimiento debería filtrar con precisión, eliminar las rutas innecesarias y verificar primero, mediante pruebas, el efecto de las nuevas reglas.

Rendimiento, estabilidad y controles de calidad

Auditoría no debe entorpecer el funcionamiento. I Comprueba periódicamente con auditctl -s, si perdido-Se producen eventos y supervisa los valores del backlog tras los cambios en las reglas. En Cuando hay una gran carga de eventos, aumento la cola del dispatcher (q_depth) de los complementos de audispd y configura overflow_action a sabiendas. Dónde execve-Si las reglas generan demasiado volumen, lo limito mediante auid o a través de exe=-Activa las listas blancas y negras, y registra solo los fallos en las llamadas al sistema ruidosas. Antes de Antes del despliegue general, valido las nuevas reglas en el entorno de prueba, mido la tasa de eventos y la carga de la CPU, y comparo aureport --summary antes y después del cambio, para cuantificar el efecto.

Entornos de contenedores y virtualización

En Además de los hosts de contenedores, el núcleo también registra los procesos de los contenedores; esto es intencionado, pero puede generar mucho ruido. I Me baso en la protección del servidor (p. ej.,. dockerd o Podman), rutas binarias y configuraciones seguras, y filtrar la vista del usuario a través de auid. Ejemplos: -w /usr/bin/dockerd -p x -k container_runtime, -w /etc/docker/ -p wa -k container_conf, además de reglas genéricas para los hosts, como execve con auid-Filtro. En En las máquinas virtuales, trato los registros de auditoría como datos volátiles: activo el reenvío remoto, configuro un intervalo de rotación corto y, en las instantáneas, me aseguro de que haya consistencia temporal. Importante Queda por garantizar una sincronización NTP/Chrony precisa para que los análisis de la línea temporal sean fiables.

Cumplimiento normativo y documentación justificativa

Para De conformidad con la norma ISO 27001 (entre otros, A.12.4 «Registro y supervisión», A.16 «Gestión de incidentes») y la norma PCI DSS (cap. 10), elaboro pruebas verificables: ¿Qué? ¿Se registra la duración, quién tiene acceso y cómo se garantiza la integridad? I Mantén la base de reglas versionada, documenta las claves y sus finalidades, firma los registros de archivo con hash y almacénalos de forma que no puedan ser manipulados. En En lo que respecta a los datos personales, aplico el principio de minimización de datos (normas específicas, plazos de conservación breves) y defino procesos de supresión claros. Así que Se elaboran informes que convencen a los auditores y que realmente aportan respuestas en caso de incidente.

Operaciones, supervisión y guías de actuación

En Para un uso continuado necesito rutinas fijas: comprobaciones aleatorias diarias con aureport, alertas en caso de perdido > 0, Comprobación de la partición de auditoría libre y del reenvío remoto. I Crea guías de actuación: „Ejecutivos que llaman la atención“ (filtro por exe= y auid), „Archivo crítico modificado“ (correlacionar con PATH, SYSCALL, EXECVE), „Intervención en el núcleo“ (normas sobre init_module y montar). Conocido Tipos de eventos como ANOM_PROMISCUOUS (Interfaz en modo promiscuo) o MAC_POLICY_LOAD (Política MAC cargada) evalúo según prioridades e inicio los pasos de respuesta.

Solución de problemas y reinicio

En Si no recibo ningún evento, lo primero que hago es comprobar ausearch -m DAEMON -ts today y auditctl -s (Estado/Pendientes). Falta Reglas: las subo con augenrules --load nuevo y comprueba con auditctl -l. Es el modo «Immutable» está activo (-e 2), lo único que ayuda es reiniciar el sistema con las reglas de inicio ajustadas. En Problemas de permisos en /var/log/audit/ Restablezco el propietario y el modo; si SELinux está activo, corrijo los contextos. Y Compruebo que log_format = RAW se establece: datos de entrada legibles para el análisis forense y los analizadores sintácticos.

Auditorías en entornos de alojamiento web

Recto En entornos de alojamiento con muchas cargas de trabajo, Auditd me ayuda a garantizar la separación de clientes de forma transparente y a detectar a tiempo cualquier uso indebido. I Supervisa los servidores web, de bases de datos y de aplicaciones mediante conjuntos de reglas por niveles e integra los eventos en los sistemas existentes de supervisión y respuesta ante incidentes. Para Me aseguro de que haya una separación clara mediante un almacenamiento centralizado, roles diferenciados y derechos restrictivos en los directorios de registros. A Como complemento al diagnóstico del sistema, recurro a ello cuando es necesario journalctl para la resolución de problemas, pero mantén los análisis críticos para la seguridad principalmente en el canal de auditoría. Así que Se crea una pista de auditoría fiable que concilia los intereses de los clientes, los requisitos de cumplimiento normativo y la eficiencia operativa.

En pocas palabras: mi método

I Empieza con un objetivo claro, establece normas específicas para los archivos críticos, la función `execve` y los cambios de privilegios, y garantiza la rotación para evitar la pérdida de datos. Entonces Activo el reenvío remoto con TLS, documento las claves y compruebo el funcionamiento de cada regla antes de implementarla a gran escala. Para En mi trabajo diario me centro en ausearch y aureport, realiza búsquedas específicas y elabora informes claros para las áreas de operaciones y seguridad. En Cuando detecto anomalías, correlaciono los eventos de auditoría con otras señales, como los datos de procesos o de red, para aislar rápidamente la causa. Así que En Linux, Auditd no me inunda de registros, sino que me ofrece respuestas claras a cuestiones relacionadas con la seguridad en entornos de producción.