La seguridad informática es un pilar fundamental para los administradores de sistemas y para las empresas que quieren mantener a salvo sus datos. Tener bien securizados nuestros servidores y sistemas es esencial para garantizar esta seguridad ante posibles intrusiones, pero igual de importante es tener controlado qué hacen los usuarios dentro de estos servidores, sin importar que sean usuarios autorizados.

Esto es precisamente lo que la auditoría de acciones y eventos del sistema nos permite lograr: tener un lugar donde poder consultar qué ha sucedido y qué se ha hecho en todo momento dentro de nuestros servidores.

En este artículo os vamos a enseñar cómo podemos obtener esta información en sistemas Linux y Windows. 

En Linux - auditd

Para cumplir nuestro propósito vamos a utilizar auditd, que es la herramienta por excelencia. Lo normal es que venga incluido en los repositorios oficiales de la distribución que estéis usando, en nuestro caso Debian, por lo que podemos instalarlo con un simple: 

apt install auditd

Una vez instalado nos tocará configurarlo para que registre en un log la información que queremos y de la forma que queremos. Empecemos por el fichero de configuración del servicio en sí que se encuentra en /etc/audit/auditd.conf y por defecto tiene este aspecto:

En esta página del manual podréis encontrar la lista completa de parámetros.

No obstante, a continuación os describimos algunos de los más importantes:

• log_file = el path completo del fichero de log donde se guardarán todas las acciones registradas por auditd (por defecto, /var/log/audit/audit.log)
• flush y freq = estos dos parámetros se usan en conjunto para definir con qué frecuencia se hace un volcado a disco de las trazas que están en memoria.
• max_log_file = determina el tamaño máximo (en MB) para el fichero de log.
• max_log_file_action = precisa qué se debe hacer cuando se alcanza el tamaño máximo permitido para el fichero de log. Las opciones son:
  • ignore = no se hará nada.
  • syslog = se enviará un mensaje de advertencia al syslog, pero no se hará nada sobre el fichero de log.
  • suspend = se dejará de escribir inmediatamente en el fichero de log.
  • rotate = se producirá un rotado de los ficheros de log. El número de ficheros de log que se desea mantener se puede definir en el parámetro 'num_logs'.
  • keep_logs = igual que 'rotate', pero no elimina el fichero de log más antiguo, sino que se van creando nuevos ficheros de log indefinidamente.
• num_logs = aquí se define el número de ficheros de log que se desea mantener si se ha fijado el valor 'rotate' para el parámetro 'max_log_file_action'.
• space_left = aquí se define un número, y si el espacio libre del disco que contiene el fichero de log desciende por debajo de este número (en megabytes), se ejecuta la acción definida en 'space_left_action'.
• space_left_action = acción a realizar cuando el espacio libre del disco del fichero de log es inferior al valor definido en 'space_left'. Opciones:
  • ignore = no hacer nada.
  • syslog = se enviará un mensaje de advertencia al syslog.
  • rotate = se producirá un rotado de los ficheros de log.
  • email = se enviará un mensaje de advertencia a la dirección de correo especificada en el parámetro 'action_mail_acct'. También se registrará en el syslog.
  • exec /path/script = se ejecutará el script definido en este path.
  • suspend = se dejará de escribir inmediatamente en el fichero de log.
  • halt = se apagará la máquina.
• disk_full_action = acción a realizar cuando el disco que contiene el fichero de log se llena por completo. Las opciones son las mismas que para 'space_left_action'

Por otro lado, tenemos las reglas y aquí es donde viene lo interesante. Con las reglas definimos qué queremos auditar y qué no. Podemos decidir si queremos auditar todas las acciones de todos los usuarios, de uno solo o de unos usuarios específicos, podemos "vigilar" un directorio concreto y auditar todos los cambios que se hagan en él, registrar los inicios de sesión, etc. Existen muchas posibilidades ya que las reglas permiten un gran nivel de personalización.

Las reglas se definen en ficheros con extensión ".rules" dentro del directorio /etc/audit/rules.d/. Por ejemplo, supongamos que queremos una regla para registrar todos los comandos ejecutados por el usuario strsistemas. Podemos crear un fichero llamado "strsistemas_actions.rules" con el siguiente contenido:
 

-a always,exit -S execve -F euid=strsistemas -k strsistemas_actions

Donde:

• -a always,exit = indica que la regla debe aplicarse siempre que un comando termine (exit). En lugar de "always" podemos utilizar "never" para conseguir el efecto contrario: que este tipo de acciones no se registren por parte de auditd.
• -S execve = especifica que la regla se aplica a la llamada al sistema execve, que se utiliza para ejecutar programas.
• -F euid=strsistemas = aquí es donde filtramos para capturar solamente los comandos del usuario strsistemas. Si quisiéramos capturar los de todos los usuarios, bastaría con no añadir esta parte.
• -k strsistemas_actions = con este parámetro añadiremos el tag "strsistemas_actions" a estos registros. Esto es útil ya que con la herramienta ausearch podremos consultar registros filtrando por etiquetas sin que tengamos que estar accediendo directamente al fichero de log.

Una vez aplicada la regla (y reiniciado el servicio auditd) probamos a eliminar con el usuario strsistemas el fichero "ejemplo1.txt" que se encuentra en el subdirectorio "subdirectorio1" mientras estamos situados en el directorio "/pruebas", y vemos que esta acción queda registrada en el log. Gracias al campo uid=1000 y al tag "strsistemas_actions" sabemos que la acción la realizó el usuario strsistemas:

Como dijimos antes, las reglas permiten un gran nivel de personalización para auditar diferentes acciones y eventos. En la documentación tenéis todos los parámetros que se admiten.

En Windows – Visor de eventos

En entornos Windows el propio sistema nos da la posibilidad de elegir lo que queremos auditar activando lo que llaman directivas de auditoría para que posteriormente las acciones y eventos deseados queden reflejados en el Visor de eventos.

Lo primero que tenemos que hacer es abrir el Editor de directivas de grupo, para ello debemos pulsar la Tecla Windows + R, escribir gpedit.msc y ejecutar.

Una vez abierto el Editor de directivas de grupo nos situaremos en estas dos ramas:

• Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Directivas de auditoría

• Configuración del equipo > Configuración de Windows > Configuración de seguridad > Configuración de directiva de auditoría avanzada > Directivas de auditoría del sistema 

En la columna de la derecha es donde podemos definir qué es lo que queremos auditar: el inicio y cierre de sesión por parte de los usuarios, los eventos del sistema, la modificación de carpetas y archivos, la modificación de permisos,etc. 

Algo importante a tener en cuenta es que para auditar el acceso y modificación de carpetas y archivos todavía nos falta un paso más. Deberemos ir a la carpeta en cuestión, hacer click derecho en ella e ir a la pestaña “Seguridad”. Una vez en ella, haremos click en “Opciones avanzadas” y se abrirá una nueva ventana. Dentro de ella nos vamos a la pestaña “Auditoría”, damos click en “Agregar” y en la nueva ventana que se abrirá es donde podremos configurar todo aquello que queramos auditar (si en “Entidad de seguridad” elegimos “Todos”, se auditarán las acciones seleccionadas para todos los usuarios. Podemos elegir usuarios o grupos de usuario específicos en lugar de “Todos”).

Ahora sí, podemos irnos al Visor de eventos y podemos comprobar que si con nuestro usuario “Administrador” eliminamos el archivo “documentoest.txt” dentro de la carpeta “carpetaTest” que hemos configurado anteriormente, esta acción ha quedado registrada:

Así mismo, también podemos ver otros eventos como por ejemplo cuando cerramos sesión:

Conclusión

Esperamos que este artículo os haya resultado de utilidad a la hora de poner en marcha un sistema para tener controlados las acciones y eventos que se generan en vuestro servidor.

No olvidéis que todo lo que hemos cubierto en este artículo es para tener logs de manera local. En entornos donde tengáis varios servidores, sería conveniente implementar alguna herramienta para el envío de estos logs a un sistema centralizado que facilite las auditorías y demás revisiones de seguridad.

¡Os esperamos de nuevo en nuestra newsletter y blog dentro de 15 días!