Análisis de logs en Bases de datos

PruebaMariadb pilotopara conanálisis Mariadb.de logs.

Actualización de sistema, e instalación de Apache.
sudo apt-get update
sudo apt-get install apache2
sudo sudo systemctl start apache2
sudo sudo systemctl status apache2

Actualización e instalación de MariaDB

sudo apt update
sudo apt install mariadb-server
sudo systemctl status mariadb

Una vez instalada mariadbMariadb comprobamos con el estatus:

Como no se tiene una configuración predeterminada de usuario ni password la contraseña esta vacía y el usuario por defecto es root. Ingresamos a la base de datos:

mysql -u root -p

Creamos un usuario que pueda conectarse de manera remota a las bases de datos y le otorgramosotorgamos los privilegios necesarios para acceder con los siguientes comandos.

CREATE USER 'remoto'@'%' IDENTIFIED BY '1234';
grant all privileges on *.* to 'remoto'@'%' with grant option;

Realizamos la creación del usuario saliendo de root e ingresando con usuario “remoto” de manera local.

MariaDB [(none)]>exit
mysql -u remoto -p
exit

Ingresamos de forma exitosa:

Habilitamos el acceso remoto de mariadb,Mariadb, salimos del usuario creado e ingresamos aal laarchivo configuracionde 50-server.cnfconfiguración desde el terminal y cambiamos el valor de bind address.

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Cabe destacar que esta configuración solo es recomendable para entornos de prueba, en un entorno de producción tenemos que restringir lo mas posible que dirección o direcciones IP pueden conectarse.

Reiniciamos Mariadb para aplicar los cambios.

sudo systemctl restart mariadb

Tenemos la direccion ip del servidor “192.168.24.84” con la que realizaremos la prueba remota desde nuestro terminal.

mysql -h 192.168.24.84 -P 3306 -u remoto -p

Para que se registren los logs de mariadbMariaDB se deben realizar cambios en el archivo de configuración quitando el símbolo de comentario en las siguientes lineas.

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Los logs se registran en el directorio /var/lib/mysql/server_audit.log.

InstalarLuego debemos instalar el pluggin de auditoria en el servidor mariadb.

root# mysql -u remoto -p
INSTALL SONAME 'server_audit';
show plugins;
SHOW GLOBAL VARIABLES LIKE "server_Audit%";
SET GLOBAL server_audit_events= 'CONNECT,QUERY_DML,TABLE';
SET GLOBAL server_audit_logging =ON;
SHOW GLOBAL VARIABLES LIKE "server_Audit%";
SET GLOBAL server_audit_excl_users = remoto;
SHOW GRANTS FOR 'remoto';
nano /etc/mysql/mariadb.conf.d/50-server.cnf
plugin_load=server_audit=server_audit.so
sudo systemctl restart mariadb

Instalación de rsyslog en nuestro servidor MariaDB.

apt-get install -y rsyslog

Después debemos enviar los registros al servidor de Wazuh. En /etc/rsyslog.conf,el archivo de configuración de rsyslog, deberá definir qué enviar al servidor de Wazuh, por UDP o TCP, la dirección IP del servidor de Wazuh y el puerto.

sudo nano /etc/rsyslog.conf

Para aplicar los cambios se debe reiniciar el servicio Rsyslog.

systemctl restart rsyslog

Se debe habilitar el complemento de auditoria

nano /etc/mysql/my.cnf

Reiniciamos para aplicar los cambios

systemctl restart mariadb

Para realizar una prueba usamos una contraseña incorrecta y correcta en repetidas ocasiones desde un terminal remoto:

mysql -h 192.168.24.84 -P 3306 -u remoto -p

Verificamos el archivo de auditoria.

cat /var/log/mysql/mariadb-audit.log | grep remoto

Por ultimo verificamos el archivo Syslogsyslog para confirmar que la información este correlacionada.

En el servidor configuramos la conexión remota con esta acción Wazuh también obtendrá registros de nuestro servidor MariaDB, para eso, necesitamos editar el archivo de configuración.

sudo nano /var/ossec/etc/ossec.conf

systemctl restart wazuh-manager.service

Para el archivo de logs en Wazuh, en el agente.

nano /var/ossec/etc/rules/local_rules.xml

systemctl restart wazuh-manager

Con todas las configuraciones realizadas se pueden ver las alertas en el dashboard de Wazuh-manager.

Elaboración de reglas en Wazuh manager para la auditoria de bases de datos.

El primer paso para las reglas personalizadas esta en el servidor de wazuh manager, ingresamos al archivo de configuración y añadimos el directorio de reglas personalizadas.

nano /var/ossec/etc/ossec.conf

Decodificador para MariaDB

La creación de un decoder para Mariadb es necesaria para la interpretación de Wazuh manager para posteriormente crear alertas generadas por actividades realizadas dentro de las bases de datos.
Los tipos de logs de mariadb generados por el plugin de auditoria son de la siguiente manera:

• Para el caso de conexión fallida:
  20240321 13:54:26,server2,remoto,192.168.24.68,45,0,FAILED_CONNECT,,,1045
  
• Para eliminación de base de datos y tablas 
  20240317 16:10:02,server2,remoto,192.168.24.68,31,65,QUERY,mysql,'drop database dbprueba',0
20240316 19:26:25,server2,remoto,192.168.24.68,71,140,QUERY,uno,'drop table tablapru',0

Ejemplo de decodificador:

<decoder name="mariadb-syslog">
    <prematch>^(\d+ \d\d:\d\d:\d\d),</prematch>
    <regex offset="after_prematch">^\w+,(\w+),(\S+),\d+,\d+,(\w+),</regex>
    <order>dstuser,srcip,action</order>
</decoder>

El nombre del decodificador es muy importante ya que tiene que pertenecer al grupo de decodificadores por defecto de Wazuh para que no entre en conflicto con los decodificadores que interpreta Wazuh manager si es que estos están dentro de los programas monitoreados por defecto.
Se realiza la prueba de este decodificador donde pre-match es la coincidencia de elementos al principio de cada log, y la parte de regex es la que nos importa para extraer los datos necesarios para nosotros, que se extraen en el apartado order.
Para verificar su funcionamiento tenemos una herramienta llamada decoders test en Wazuh manager que nos indica si los datos que necesitamos se pudieron extraer de forma correcta.

 

Podemos observar los tipos de logs generados por el plugin de auditoria de mariadb enviados a Wazuh manager para que sea decodificado por nuestro decodificador y posteriormente reconoce los datos requeridos como el nombre del decodificador, usuarios e IP proveniente.

Para la siguiente fase debemos crear reglas personalizadas a partir de estos decodificadores.

Reglas personalizadas para MariaDB.

Debemos crear una regla personalizada para que este detecte cuando una base de datos ha sido borrada. En este caso la regla se activa cuando Wazuh manager encuentra la palabras drop database, ingresamos al archivo de configuración.
nano /var/ossec/etc/rules/local_rules.xml

Para realizar la prueba ingresamos de forma remota 

mysql -h 192.168.24.84 -P 3306 -u remoto -p

Se crea una base de datos de prueba y se elimina.

  

Posteriormente observamos la alerta en Wazuh manager.

Posteriormente podemos realizar una regla mas en caso de que se elimine una tabla dentro de una base de datos:

Revisando las alertas generadas en el dashboard de Wazuh manager podemos observar una alerta de nivel 7 con la ubicación del archivo de log para obtener mas información.