Linux Audit Framework. La Guía Completa para Auditar tu Sistema

Muy buenas! En el post de hoy te hablaré de Linux Audit Framework, un potente entorno de auditoria integrado en GNU/Linux, con el que podrás ser capaz de disponer de un registro detallado de toda la actividad del sistema, y detectar un gran numero de eventos de interés.

Si sigues estas lineas te explicare como funciona Linux Audit Framework en su conjunto, que elementos lo componen, y las principales utilidades y comandos que debes conocer para poder sacarle el máximo provecho. ¡Vamos allá!

Tabla de contenidos:

1. ¿Linux Audit Framework. ¿Qué es y como funciona?
2. Instalar Auditd en tu distribución GNU/Linux
3. Habilitar Auditd en el arranque del sistema
4. Controlar reglas de monitorización de eventos
   1. Visualizar reglas cargadas
   2. Definir nuevas reglas no persistentes
   3. Definir nuevas reglas de forma persistente
5. Buscar en los registros de auditoria
6. Generar informes de auditoria
7. Guía de uso

Linux Audit Framework. ¿Qué es y Como Funciona?

Linux Audit Framework es un conjunto completo de herramientas y utilidades integradas como módulo en el propio kernel, y que, en su conjunto, proporcionan un potente entorno de auditoria, gracias a la monitorización todo tipo de eventos de sistema, y a contar con utilidades especificas para ayudarte en la búsqueda y reporting de dichos eventos.

Como dato a tener en cuenta, y para que te hagas una idea del enrome potencial que puede brindar, Linux Audit Framework es un sistema que cumple con el CAPP o Controlled Access Protection Profile, un estándar de seguridad desarrollado por la NSA que establece una serie de procedimientos que un sistema debería cumplir para garantizar un nivel de seguridad y control de acceso acorde.

No es para menos, ya que con Linux Audit podrás disponer de un registro detallado de toda actividad del sistema, y contarás con utilidades que te facilitarán enormemente las labores de detección y diagnóstico de todo tipo de problemas, algo especialmente crítico sobretodo cuando hablamos de incidentes de seguridad.

Auditd es el componente central de Linux Audit Framework. Es el demonio que se ejecuta en segundo plano, y que se encarga de función de monitorización del sistema en busca de cualquier evento susceptible de ser auditado. Para ello, se apoya en otros elementos del sistema, como el propio kernel, el sistema de archivos (para detectar cambios a nivel de archivos), o el sub-sistema de red (para registrar actividad de red).

Auditd es capaz de detectar un gran número de eventos, y también es altamente ajustable en cuanto a reglas de detección, para que puedas adaptarlo a las necesidades de auditoria concretas de cada entorno. Entre los muchos eventos que puede detectar, se encuentran:

• Inicios de sesión, tanto exitosos como fallidos, incluyendo información como la hora del evento, el usuario que intentó iniciar sesión, y el resultado del intento.
• Cambios en archivos críticos, como /etc/passwd, /etc/shadow, /etc/group, etc.
• Ejecución de comandos concretos, incluyendo el comando e si y el usuario que lo ejecutó.
• Acceso a recursos del sistema, como dispositivos de almacenamiento, redes, etc.
• Cambios en políticas de seguridad, ya sea a nivel de cortafuegos, permisos en archivos, etc.

Cuando Auditd detecta un evento de los que tiene catalogados como de interés, lo registra en un archivo concreto, indicando el tipo de evento, la fecha, y el usuario o proceso involucrado.

Auditd se apoya, al mismo tiempo, en un conjunto de utilidades adicionales, para facilitar la interacción por parte de los usuarios, a la hora de crear nuevas reglas de monitorización, buscar eventos, etc. Estas herramientas son:

• auditctl. Permite controlar el estado de Auditd, y añadir o quitar reglas de auditoria en tiempo real.
• augenrules. Es un script que se encarga de hacer un merge de todos los archivos de reglas definidos en
• ausearch. Se utiliza para buscar y filtrar eventos de auditoria que hayan sido registrados.
• aureport. Se utiliza para poder generar informes de auditoria, en base a los diferentes eventos registrados.

Instalar Auditd en tu Distribución GNU/Linux

En caso de que quieras sacar el máximo provecho de Linux Audit Framework, es necesario que instales Auditd, el demonio que se encarga de la labor de monitorización, y que no suele venir pre-instalado en la mayoría de distribuciones GNU/Linux.

Si quieres instalar Auditd en tu sistema, en el caso de Debian, Ubuntu, y el conjunto de sus derivados, lo puedes hacer con el siguiente comando:

sudo apt install auditd

Si, por contra, te encuentras en Fedora, que utiliza el gestor de paquetes DNF, puedes instalar Auditd con el siguiente comando:

sudo dnf install auditd

Habilitar Auditd en el Arranque del Sistema

Al instalar Auditd, por lo general, también se habilitará su ejecución en segundo plano, a partir del próximo reinicio. Puedes controlar el estado de Auditd en todo momento a través de systemctl, ejecutando el siguiente comando:

sudo systemctl status auditd

Para habilitar el servicio en segundo plano, en caso de que no lo estuviera, puedes utilizar el siguiente comando:

sudo systemctl enable auditd

Controlar Reglas de Monitorización de Eventos

Por defecto, Auditd ya viene configurado con un conjunto de reglas básicas que se encargan de monitorizar ciertos eventos del sistema.

• Watches o reglas de control sobre el sistema de archivos. Permiten controlar eventos relacionados con archivos y directorios específicos, ya sea a nivel de controlar cuando un archivo o directorio es accedido, editado, ejecutado, o se
• Syscalls o llamadas a sistema. Permiten detectar llamadas de sistema realizadas al kernel por parte de cualquier servicio o aplicación.

Visualizar Reglas Cargadas

El conjunto de reglas que son cargadas por el demonio Auditd cada vez que arranca vienen contenidas en el archivo /etc/audit/audit.rules. Puedes consultar su contenido con cualquier editor de código, tal como te muestro debajo (utilizando Vim):

sudo vim /etc/audit/audit.rules

Si acabas de instalar Auditd y no has definido reglas especificas de forma persistente, lo más probable es que no te aparezca ninguna regla por defecto ahí. Asimismo, si añades reglas de forma discrecional, pero que no son persistentes entre reinicios, estas tampoco aparecerán aqui.

Si quieres controlar las reglas que tenga cargadas Auditd en tiempo real, puedes hacerlo utilizando auditctl, tal como te muestro a continuación. Con este comando podrás ver todas las reglas que están cargadas en este mismo momento, aunque no sean persistentes entre reinicios.

sudo auditctl -l

En este momento, si acabas de instalar Auditd, es posible que no aparezca ninguna regla aquí. A medida que vayas añadiendo diferentes reglas, sin embargo, aunque sea de forma no persistente, las podrás ver listadas con la salida de este comando.

Definir Nuevas Reglas no Persistentes

Es el momento de empezar con la creación de reglas. De momento me centraré en la creación de reglas de forma discrecional, para que apliquen en el mismo momento, pero que no sean persistentes entre reinicios.

Para eso, necesitas utilizar igualmente adminctl, tal como has visto hace un momento. A continuación te enseñaré los comandos que debes utilizar para la creación de reglas de tipo watch y de tipo syscall, junto con varios ejemplos prácticos en cada caso.

Para añadir una nueva regla de tipo watch, o de control sobre el sistema de archivos, debes regirte por la sintaxis que te muestro en el comando de debajo:

sudo auditctl -w ruta -p selectores-permiso

La sintaxis que te acabo de mostrar arriba debes utilizarla de la siguiente manera:

• -w es para indicar que la regla que estás creando es de tipo watch.
• ruta debes sustituirlo por la ruta del fichero o directorio sobre el que quieres crear el watch.
• -p sirve para indicar que a continuación se van a especificar los selectores de permisos.
• selectores-permiso debes sustituirlo por uno o varios de los siguientes selectores, según el tipo de evento sobre el directorio que te interesa monitorizar:
  • r (lectura)
  • w (escritura)
  • x (ejecución)
  • a (atribución)
• -k es un parámetro opcional que puedes utilizar en caso de que quieras añadir a continuación un nombre o palabra clave para identificar la regla o grupo de reglas.
• keyword debes sustituirlo por la palabra clave concreta con la que quieres identificar esa regla (puedes utilizar la misma palabra con diferentes reglas, si quieres agruparlas en una categoría concreta).

Ahora que tenemos clara la sintaxis, si te parece, veamos algunos ejemplos prácticos, utilizando algunos de los casos que se suelen utilizar más en el mundo real.

Como primer ejemplo, voy a añadir una regla de control sobre la ruta /etc/passwd, que corresponde a un fichero que almacena información de todas las cuentas de usuario, como el nombre, UID, GID, etc. Al ser un archivo tan importante, vamos incluir todos los selectores de permisos, para tener en cuenta tanto acceso, edición, ejecución o atribución.

sudo auditctl -w /etc/passwd -p rwxa

Otro archivo de interés, muy relacionado con el anterior, es /etc/shadow, que en este caso es donde se guardan los hashes de las contraseñas de las diferentes cuentas de usuario. Al igual que en el caso anterior, podemos contemplar todos los selectores de permisos antes mencionados.

sudo auditctl -w /etc/shadow -p rwxa

En este otro ejemplo que te copio debajo, añadiré una regla de control sobre el directorio /etc/default/ufw, que es donde están almacenados los ficheros de configuración y reglas de ufw a nivel de cortafuegos (en el caso de que utilices ufw como utilidad para interactuar con netfilter/iptables). En este caso solo he añadido los selectores de permisos de edición y atribución, que son los más relevantes en este caso.

sudo auditctl -w /etc/default/ufw -p wa

Estos han sido solo unos pocos ejemplos, en lo que respecta a las reglas de tipo watch. Si investigas un poco más, seguro que encuentras muchos otros directorios de interés para ser contemplados aquí, pero ahora centrémonos en las reglas de tipo syscall.

Para crear una regla de tipo syscall o de llamada a sistema, debes regirte por la sintaxis que te muestro a continuación:

auditctl -a action,filter -S syscall -F field=value -k keyword

Esta sintaxis que te acabo de mostrar puedes entenderla de la siguiente manera:

• -a es para indicar que la regla que estás creando es de tipo syscall.
• action indica cuando debe ser registrado el evento, y puedes sustituirlo por uno de los siguientes valores:
  • always
  • never
• filter especifica que filtro a nivel de kernel debe ser aplicado, y puedes sustituirlo por uno de los siguientes valores:
  • user
  • task
  • exclude
  • exit
• -S sirve para indicar que a continuación vas a especificar la llamada a sistema.
• syscall debes sustituirlo por el nombre de la llamada a sistema que quieres monitorizar.
• -F sirve para indicar que a continuación vas a especificar una opción adicional de tipo field=value.
• field=value sirve para aplicar opciones adicionales, por ejemplo, para filtrar solo los eventos basados en una arquitectura concreta, o a un determinado PID.
• -k es un parámetro opcional que puedes utilizar en caso de que quieras añadir a continuación un nombre o palabra clave para identificar la regla o grupo de reglas.
• keyword debes sustituirlo por la palabra clave concreta con la que quieres identificar esa regla (puedes utilizar la misma palabra con diferentes reglas, si quieres agruparlas en una categoría concreta). Esto te puede servir sobretodo para poder hacer filtros en base a esa palabra, a la hora de buscar eventos en los registros de auditoria.

Visto así lo cierto es que parece bastante confuso a primera vista, pero con los ejemplos que te expondré a continuación te harás una idea más clara, y, de paso, conocerás casos concretos que pueden ser de interés real a la hora de establecer reglas a nivel de llamadas al sistema.

Como primer ejemplo, voy a utilizar un caso típico, que consiste en monitorizar todas las operaciones de ejecución de programas. Para ello, debes utilizar la acción always y el filtro exit. El nombre de la llamada a sistema que debes indicar detrás de -S es execve, y, detrás de -F indicaremos la orden de filtrar la llamada a nivel de arquitectura, con arch=b64. Finalmente, de forma opcional, especifico la palabra clave ejecucion, que nos servirá como parámetro para hacer filtros a la hora de buscar eventos.

auditctl -a always,exit -S execve -F arch=b64 -k ejecucion

En este ejemplo seré un poco más concreto, y trataré de monitorizar los intentos de ejecución, como en el caso anterior, pero únicamente en el directorio /bin. Para ello, la llamada de sistema es igualmente execve, pero, detrás de -F, el filtro que indicaré es dir=/bin, para acotar la llamada a nivel de este directorio.

auditctl -a always,exit -S execve -F dir=/bin -k ejecucion

Otro ejemplo interesante consiste en monitorizar las operaciones de clonación de procesos. En este caso, el nombre de la llamada a sistema que hay que indicar detrás del parámetro -S es clone. Detrás de -F también podemos establecer un filtro a nivel de arquitectura. Al final, detrás de -k, indicaré la palabra clave con la que quiero identificar esta regla es clonacion.

auditctl -a always,exit -S clone -F arch=b64 -k clonacion

Es importante tener en cuenta que las reglas de auditoria agregadas a través este procedimiento no son permanentes, ya que al reiniciar el equipo, el script augenrules se encarga de fusionar los archivos de reglas existentes en el directorio /etc/audit/rules.d/ hacía el archivo /etc/audit/audit.rules, que es el que carga las reglas que aplicarán en el arranque del servicio.

Definir Nuevas Reglas de forma Persistente

Si lo que quieres es definir reglas que sean persistentes en cada reinicio, debes agregarlas en un fichero dentro del directorio /etc/audit/rules.d. Puedes añadirlas en el propio archivo /etc/audit/rules.d/audit.rules que ya viene por defecto, o utilizar un archivo personalizado, para no ensuciar el original.

Como recomendación personal, yo optaría por añadirlas en un archivo aparte. Así, si quieres volver al estado por defecto, solo deberás eliminar ese archivo y listo.

En este caso, puedes crear un archivo con el nombre que quieras, pero debe terminar si o si con la extensión .rules, ya que el script augenrules únicamente tendrá en cuenta ese tipo de archivos a la hora de fusionar el conjunto de reglas en /etc/audit/audit.rules.

En este caso, voy a generar un archivo nuevo, denominado custom.rules, y voy a añadir algunas de las reglas que hemos definido en el apartado anterior. Para crear el fichero y abrirlo, puedes utilizar el siguiente comando (yo utilizo Vim como editor de código, pero puedes utilizar cualquier otro):

sudo vim /etc/audit/rules.d/custom.rules

A continuación, solo tienes que añadir las diferentes reglas personalizadas que quieres que apliquen, una a una. En este caso voy a añadir las mismas que hemos utilizado antes.

# Reglas de control sobre el sistema de archivos
-w /etc/shadow -p wa
-w /etc/passwd -p wa
-w /etc/default/ufw -p wa

# Reglas de llamadas a sistema
-a always,exit -S execve -F arch=b64 -k ejecucion
-a always,exit -S clone -F arch=b64 -k clonacion

Hecho eso, solo te queda guardar el archivo y reiniciar el equipo. En el próximo arranque verás que todas esas reglas han sido añadidas en el archivo /etc/audit/audit.rules, que es el que carga las reglas que deben aplicar en cada arranque del servicio.

sudo vim /etc/audit/audit.rules

Estas reglas también las podrás visualizar ejecutando el siguiente comando, y que ya has visto antes:

sudo auditctl -l

Buscar en los Registros de Auditoria

Ahora que ya sabes como crear reglas personalizadas para ampliar el ámbito de actuación de Auditd, pasemos a ver como sacar provecho de todo ello, a la hora de buscar y localizar eventos concretos. En este caso, la utilidad que necesitarás es ausearch. A continuación tienes algunos ejemplos.

Para listar todos los eventos que tengan que ver un un proceso concreto, identificado por el PID, puedes utilizar el comando que te muestro aqui debajo, sustituyendo PID por el ID del proceso en cuestión.

sudo ausearch -p PID

Si a la hora de definir reglas personalizadas has hecho uso del parámetro -k para asociar una palabra clave a dichas reglas, aquí te será de gran utilidad, ya que puedes utilizar ausearch para buscar específicamente por eventos que tengan que ver con reglas que tenga esa palabra clave. Para ello tan solo debes ejecutar el comando de debajo, sustituyendo keyword por la palabra clave por la que quieras buscar.

sudo ausearch -k keyword

También puedes listar todos los eventos relacionados con un determinado archivo o directorio. En este caso debes utilizar el siguiente comando, sustituyendo ruta por la ruta concreta en la que se encuentra el archivo o directorio sobre el que quieres buscar.

sudo ausearch -f ruta

Puedes hacer lo mismo pero guiándote por las llamadas al sistema. En este caso, para buscar todos los eventos relacionados con una determinada llamada a sistema, puedes utilizar el comando que te copio debajo, sustituyendo syscall por el nombre de la llamada a sistema en cuestión.

sudo ausearch -sc syscall

Estos son solo algunos ejemplos de como utilizar ausearch. Como ves, es una herramienta enormemente útil, sobretodo cuando estás buscando por un evento o conjunto de eventos en concreto, para investigar, por ejemplo, un posible incidente de seguridad.

Generar Informes de Auditoria

Otra opción interesante, y complementaria a la de búsqueda de eventos concretos que acabas de ver, es la de generar informes de auditoria, con un resumen general de varios datos agregados, y sin incidir necesariamente en eventos concretos. Esto es útil sobretodo para detectar cuando hay indicadores que se desvíen significativamente de lo habitual. Para eso, la utilidad que utilizaré es aureport.

En este primer ejemplo utilizaré aureport para generar un informe que resuma varios indicadores concretos, en base a los eventos que ha ido monitorizando Auditd. Para ello tan solo debes ejecutar el comando de debajo:

sudo aureport --summary

Otra opción interesante, por ejemplo, es la de generar un informe de todos los inicios de sesión fallidos. Para ello debes utilizar el parámetro -i, referente al evento de inicio de sesión, junto con la opción --failed, para filtrar por los inicios que han sido falllidos.

sudo aureport --failed