Auditoría de Eventos del Sistema en Linux: Guía Completa

Una de las herramientas que permite mejorar la seguridad en Linux es el sub-sistema de auditoría. Con ella puedes obtener información detallada sobre todos los eventos del sistema.

No ofrece ninguna protección adicional, pero te da información detallada sobre las violaciones de seguridad, lo que te permite tomar medidas concretas. En este artículo veremos cómo funciona el sub-sistema de auditoría.

Subsistema de Auditoría: Arquitectura y Principio de Funcionamiento

El subsistema de auditoría se agregó al kernel de Linux a partir de la versión 2.6. Está diseñada para rastrear eventos críticos del sistema desde el punto de vista de la seguridad. Algunos ejemplos de estos eventos son (la lista no es exhaustiva):

• Inicio y cierre del sistema.
• Lectura, escritura y cambio de permisos de acceso a archivos.
• Iniciación de conexiones de red.
• Intentos de autorización fallida en el sistema.
• Cambio de configuración de red.
• Cambio de información sobre usuarios y grupos.
• Inicio y detención de aplicaciones.
• Ejecución de llamadas al sistema.

Lee más aquí sobre Registros de Eventos de Linux y sus Tipos de Registro.

Ninguno de estos eventos puede ocurrir sin usar llamadas al sistema del kernel. Para rastrearlos, simplemente tienes que interceptar las llamadas al sistema correspondientes. Eso es precisamente lo que hace el sub-sistema de auditoría:

Al recibir una llamada de una aplicación en el espacio del usuario, el sub-sistema de auditoría la pasa por uno de los siguientes filtros: user, task o exit (hablaremos de ellos con más detalle más adelante). Después, la llamada se pasa por el filtro exclude, que según las reglas de auditoría la transfiere al demonio auditd para que la procese más a fondo.

Este sencillo esquema permite rastrear de forma eficaz cualquier aspecto del funcionamiento del SO y, en caso de que el sistema se vea comprometido, detectar acciones sospechosas y determinar su causa.

Instalación de auditd

Para empezar a trabajar con el sub-sistema de auditoría, tienes que instalar el paquete auditd (a continuación se dan ejemplos de comandos para el SO Ubuntu 14.04):

sudo apt-get install auditd

Este paquete incluye el demonio auditd y varias utilidades auxiliares:

• auditctl: utilidad para administrar el demonio auditd; permite obtener información sobre el estado actual del sub-sistema de auditoría, así como agregar y eliminar reglas.
• autrace: utilidad para auditar eventos generados por procesos (funciona según el mismo principio que strace).
• ausearch: utilidad para buscar eventos en los archivos de registro.
• aureport: utilidad para generar informes sobre el funcionamiento del sistema de auditoría.

Configuración del Subsistema de Auditoría

La configuración del subsistema de auditoría se almacena en el archivo de configuración etc/audit/auditd.conf. Entre otros, contiene los siguientes parámetros:

• log_file: archivo donde se almacenarán los registros del sub-sistema de auditoría.
• log_format: formato en el que se guardarán los registros.
• freq: número máximo de registros de protocolo que se pueden almacenar en el búfer.
• flush: modo de sincronización del búfer con el disco (none: no hacer nada, incremental: transferir datos del búfer al disco con la frecuencia indicada en el valor del parámetro freq; data: sincronizar inmediatamente, sync: sincronizar tanto los datos como los metadatos del archivo al escribir en el disco).
• max_log_file: tamaño máximo del archivo de registro en megabytes.
• max_log_file_action: acción que se debe realizar al superar el tamaño máximo del archivo de registro.
• space_left: mínimo de espacio libre en megabytes que debe haber para que se ejecute la acción indicada en el siguiente parámetro.
• space_left_admin: indica qué hacer cuando no hay suficiente espacio libre en el disco (ignore: no hacer nada, syslog: enviar al syslog, email: enviar una notificación por correo electrónico, suspend: dejar de escribir registros en el disco, single: pasar al modo de un solo usuario, halt: apagar la máquina).
• disk_full_action: acción que se debe realizar cuando el disco está lleno (este parámetro puede tomar los mismos valores que space_left_admin).

Creación de Reglas

Para agregar y configurar reglas, se usa el comando auditctl. Esta es una lista de sus opciones:

• -l: mostrar una lista de las reglas existentes.
• -a: agregar una nueva regla.
• -d: eliminar una regla de la lista.
• -D: eliminar todas las reglas existentes.

Para crear una nueva regla, tienes que ejecutar un comando de este tipo:

$ auditctl -a <lista>, <acción> -S <nombre de la llamada al sistema> -F <filtros>

Primero, después de la opción -a, se indica la lista a la que se debe agregar la regla. En total, hay 5 listas:

• task: eventos relacionados con la creación de nuevos procesos.
• entry: eventos que tienen lugar al entrar en una llamada al sistema.
• exit: eventos que tienen lugar al salir de una llamada al sistema.
• user: eventos que usan parámetros del espacio del usuario.
• exclude: se utiliza para excluir eventos.

Luego, se indica qué se debe hacer después de que se produzca el evento. Aquí hay dos opciones posibles: always (los eventos se registrarán en el diario) y never (no se registrarán).

Después de la opción -S va el nombre de la llamada al sistema con la que se debe interceptar el evento (open, close, etc.).

Después de la opción -F se indican los parámetros adicionales de filtrado. Por ejemplo, si necesitas auditar las llamadas a archivos del directorio /etc, la regla tendrá este aspecto:

auditctl -a exit,always -S open -F path =/etc/

Puedes configurar un filtro adicional:

auditctl -a exit,always -S open -F path =/etc/ -F perm = aw

La abreviatura aw significa lo siguiente: a: cambio de atributo (attribute change), w: escritura (write). La formulación perm = aw indica que para el directorio /etc se deben rastrear todos los hechos de cambio de atributos (a: attribute change) y w (w: write).

Al configurar el seguimiento de archivos individuales, puedes omitir la opción -S, por ejemplo:

auditctl -a exit,always -F path =/etc/ -F perm = aw

Archivos de Reglas

Las reglas no solo se pueden configurar a través de la línea de comandos, sino que también se pueden escribir en el archivo etc/audit/audit.rules.

Este archivo comienza con las llamadas metareglas, en las que se configuran las opciones generales de registro:

# eliminar todas las reglas creadas anteriormente
-D

# configurar la cantidad de buffers en los que se almacenarán los mensajes
-b 320

# indicar qué hacer en una situación crítica (por ejemplo, cuando los buffers se llenan): 
0: no hacer nada; 1: enviar un mensaje a dmesg, 2: enviar el kernel al estado de pánico
-f 1 

A continuación, siguen las reglas del usuario. Su sintaxis es extremadamente sencilla: basta con enumerar las opciones correspondientes del comando auditctl. Veamos un ejemplo de archivo de reglas típico:

# rastrear las llamadas al sistema unlink() y rmdir()
-a exit,always -S unlink -S rmdir

# rastrear las llamadas al sistema open() del usuario con UID 1001
-a exit,always -S open -F loginuid=1001

# rastrear el acceso a los archivos de contraseñas y grupos y los intentos de modificarlos:
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa

# rastrear el acceso al siguiente directorio:
-w /etc/my_directory -p r

# cerrar el acceso al archivo de configuración para evitar modificaciones
-e 2

Los cambios en la configuración entrarán en vigor después de reiniciar el demonio auditd:

sudo service auditd restart

Análisis de Archivos de Registro: Utilidad aureport

Todos los archivos de registro se guardan en el directorio /var/log/audit en formato legible por máquina. Puedes convertirlos en un formato legible por humanos con la utilidad aureport.

Si ejecutas el comando aureport sin argumentos, verás las estadísticas generales del sistema (cantidad de usuarios del sistema, cantidad total de llamadas al sistema, cantidad de terminales abiertos, etc.):

sudo aureport

Summary Report
======================
Range of time in logs: 07/31/2024 14:04:23.870 - 08/04/2024 09:37:13.200
Selected time for report: 07/31/2024 14:04:23 - 08/04/2024 09:37:13.200
Number of changes in configuration: 0
Number of changes to accounts, groups, or roles: 3
Number of logins: 0
Number of failed logins: 0
Number of authentications: 0
Number of failed authentications: 61205
Number of users: 2
Number of terminals: 5
Number of host names: 73
Number of executables: 6
Number of files: 0
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 0
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of keys: 0
Number of process IDs: 17858
Number of events: 61870

No tiene mucho valor práctico. Los informes especializados son mucho más interesantes. Por ejemplo, así es como puedes ver la información sobre todas las llamadas al sistema:

sudo aureport -s

Syscall Report
=======================================
# date time syscall pid comm auid event
=======================================
1. 08/03/2024 15:45:03 313 10285 modprobe -1 52501
2. 08/03/2024 15:45:03 313 10290 modprobe -1 52502
3. 08/03/2024 15:45:03 54 10296 iptables -1 52503
4. 08/03/2024 15:45:03 54 10302 iptables -1 52504
5. 08/03/2024 15:45:03 54 10305 iptables -1 52505
6. 08/03/2024 15:45:03 54 10313 iptables -1 52506
7. 08/03/2024 15:45:03 54 10325 iptables -1 52507
8. 08/03/2024 15:45:03 54 10329 iptables -1 52508
9. 08/03/2024 15:45:03 54 10343 iptables -1 52509
10.08/03/2024 15:45:03 54 10345 iptables -1 52510
11.08/03/2024 15:45:03 54 10349 iptables -1 52511

Si usas la opción -au (o −−auth), puedes ver la información sobre todos los intentos de inicio de sesión en el sistema:

$ sudo aureport -au 

Authentication Report
============================================
# date time acct host term exe success event
============================================
1. 08/31/2024 18:00:19 ubnt static-166-6-249-80.stalowa.pilicka.pl ssh /usr/sbin/sshd no 333
2. 08/31/2024 18:01:38 root 59.63.188.31 ssh /usr/sbin/sshd no 334
3. 08/31/2024 18:01:41 root 59.63.188.31 ssh /usr/sbin/sshd no 335
4. 08/31/2024 18:01:45 root 59.63.188.31 ssh /usr/sbin/sshd no 336
5. 08/31/2024 18:01:53 root 59.63.188.31 ssh /usr/sbin/sshd no 337
6. 08/31/2024 18:01:57 root 59.63.188.31 ssh /usr/sbin/sshd no 338
7. 08/31/2024 18:01:59 root 59.63.188.31 ssh /usr/sbin/sshd no 339

En aureport se admite la filtración por fecha y hora:

$ sudo aureport -s --start 07/31/24 12:00 --end 07/31/24 13:00

Puedes indicar tanto la hora y la fecha concretas como construcciones especiales comprensibles por humanos:

• now: momento actual.
• yesterday: día anterior.
• recent: hace 10 minutos.
• this-week (o this-month, this-year): semana actual (mes, año).

Con aureport puedes ver información sobre las acciones de cualquier usuario del sistema. Para ello, primero tienes que saber el id de ese usuario:

id user
uid=1000(user) gid=1000(andrei) groups=1000(andrei),27(sudo)

y luego ejecutar el siguiente comando:

sudo ausearch -ui 1000 --interpret

Ausearch: Búsqueda y Análisis de Eventos

Para ver información detallada sobre un evento, se usa la utilidad ausearch:

sudo ausearch -a <número de evento> 

La salida del comando anterior tendrá este aspecto:

type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config"

Analicemos su estructura con más detalle. En el campo type se indica el tipo de registro; type = syscall significa que el registro se realizó después de ejecutar una llamada al sistema. En el campo msg se indica la hora del evento en formato Unix Timestamp y su número de identificación único.

El campo arch contiene información sobre la arquitectura del sistema que se está utilizando (c000003e significa x86_84), representada en formato hexadecimal codificado. Para que se muestre en formato legible por humanos, puedes usar la opción -i o −−interpret.

En el campo syscall se indica el tipo de llamada al sistema; en nuestro caso, es 2, es decir, la llamada open. El parámetro success informa sobre si la llamada se procesó correctamente o no. En nuestro ejemplo, la llamada se procesó sin éxito (success = no).

Para cada llamada, el informe también enumera los parámetros individuales; puedes encontrar más información sobre ellos en el manual oficial. Puedes obtener información sobre cualquier parámetro en formato legible por humanos mediante la opción -i o −−interpret mencionada anteriormente, por ejemplo:

sudo ausearch --interpet --exit  -13

La opción -sc te permite incluir en la lista eventos relacionados con la llamada al sistema especificada, por ejemplo:

sudo ausearch -sc ptrace

La opción -ui sirve para buscar eventos según el identificador del usuario:

ausearch -ui 33

La búsqueda por nombre de demonios se realiza con la opción -tm:

ausearch -x -tm cron

Para buscar los eventos necesarios también puedes usar claves, por ejemplo:

sudo auditctl -k root-actions

El comando anterior mostrará una lista de todas las acciones realizadas en nombre del usuario root. También se admite la filtración por fecha y hora, similar a la que se describió anteriormente. Puedes ver una lista de eventos que terminaron sin éxito con la opción −−failed.

Análisis de Procesos con la Utilidad autrace

En algunos casos, puede ser útil obtener información sobre los eventos relacionados con un proceso concreto. Para ello, puedes usar la utilidad autrace. Supongamos que necesitas rastrear el proceso date y saber qué llamadas al sistema y archivos utiliza. Ejecuta el comando:

sudo autrace /bin/date

En la consola aparecerá el siguiente texto:

Waiting to execute: /bin/date
Mon Aug 31 17:06:32 MSK 2024
Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 29234'

Fíjate en la última línea de salida: indica el comando con el que puedes obtener información más detallada. Ejecutemos este comando y pasemos la salida a la utilidad aureport, que la convertirá a un formato legible por humanos:

sudo ausearch -p 29215 --raw | aureport -f -i

Como resultado, obtendremos el siguiente informe:

File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. 08/31/2024 16:52:16 /bin/date execve yes /bin/date root 25
2. 08/31/2024 16:52:16 /etc/ld.so.nohwcap access no /bin/date root 27
3. 08/31/2024 16:52:16 /etc/ld.so.preload access no /bin/date root 29
4. 08/31/2024 16:52:16 /etc/ld.so.cache open yes /bin/date root 30
5. 08/31/2024 16:52:16 /etc/ld.so.nohwcap access no /bin/date root 34
6. 08/31/2024 16:52:16 /lib/x86_64-linux-gnu/libc.so.6 open yes /bin/date root 35
7. 08/31/2024 16:52:16 /usr/lib/locale/locale-archive open yes /bin/date root 52
8. 08/31/2024 16:52:16 /etc/localtime open yes /bin/date root 56

Almacenamiento Centralizado de Registros (logs)

Para enviar los registros del subsistema de auditoría a un almacén centralizado, se usa el plugin audisp-remote. Este plugin forma parte del paquete audisp-plugins, que se debe instalar por separado:

sudo apt-get install audisp-plugins

Los archivos de configuración de todos los plugins se almacenan en el directorio /etc/audisp/plugins.d.

La configuración del registro remoto se escribe en el archivo de configuración /etc/audisp/plugins.d/audisp-remote.conf. Por defecto, este archivo tiene este aspecto:

active = no
direction = out
path = /sbin/audisp-remote
type = always
#args =
format = string

Para activar el envío de registros al almacén remoto, cambia el valor del parámetro active a yes. Luego, abre el archivo etc/audisp/audisp-remote.conf e indica como valor del parámetro remote_server la dirección de letras o IP del servidor donde se almacenarán los registros.

Para recibir registros de hosts remotos y guardarlos en el servidor, en el archivo /etc/audit/auditd.conf tienes que escribir los siguientes parámetros:

tcp_listen_port = 60
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535 #opcional
tcp_client_max_idle = 0

Conclusión

En este artículo, hemos presentado los conceptos básicos del funcionamiento del subsistema de auditoría de Linux. Hemos analizado el principio de funcionamiento del sistema de auditoría, hemos aprendido a formular reglas, leer registros y usar utilidades auxiliares.

Para quienes deseen estudiar el tema con más detalle, les damos algunas referencias útiles:

• Lista completa de tipos de registros de auditoría;
• Lista completa de eventos posibles;
• Artículo sobre la utilización de las funciones de auditoría para investigar ataques al kernel.

Invitamos a los lectores que no puedan dejar comentarios aquí a nuestro blog.