# Wazuh - Open Source XDR. Open Source SIEM

Wazuh es un sistema de detección de intrusos basado en host de código abierto y libre. Realiza análisis de registro, comprobación de integridad, supervisión del registro de Windows, detección de rootkits, alertas basadas en el tiempo y respuesta activa

# Instalación Wazuh Open Source security

#### <span style="color: rgb(53, 152, 219);">**Introducción.**</span>

Wazuh es una plataforma de seguridad gratuita y de código abierto que unifica las capacidades XDR y SIEM. Protege cargas de trabajo en entornos locales, virtualizados, en contenedores y basados ​​en la nube.

Wazuh ayuda a organizaciones e individuos a proteger sus activos de datos contra amenazas a la seguridad. Es ampliamente utilizado por miles de organizaciones en todo el mundo, desde pequeñas empresas hasta grandes empresas.

Antes de realizar la instalación del Manager de Wazuh y los agentes se debe verificar que la lista de repositorios este actualizada ya que influye en los siguientes aspectos:

Seguridad:

- Corrección de vulnerabilidades: Los repositorios se actualizan constantemente para corregir vulnerabilidades de seguridad. Si no se actualiza, su sistema estará vulnerable a ataques.
- Software desactualizado: El software desactualizado puede tener vulnerabilidades de seguridad sin parches.

Estabilidad y rendimiento:

- Corrección de errores: Las actualizaciones de software corrigen errores que pueden causar inestabilidad o problemas de rendimiento.
- Mejoras de rendimiento: Las actualizaciones de software pueden mejorar el rendimiento general del sistema.

Nuevos paquetes y versiones:

- Acceso a nuevas funciones: Las actualizaciones de software agregan nuevas funciones y mejoras.
- Compatibilidad con hardware nuevo: Las actualizaciones de software pueden agregar compatibilidad con hardware nuevo.

#### <span style="color: rgb(53, 152, 219);">**Instalación de Wazuh.**</span>

La solución Wazuh se compone de tres componentes de plataforma central y un único agente universal. Para instalar Wazuh en tu infraestructura el inicio rápido es una forma automatizada de instalar Wazuh en tan solo unos minutos, es recomendable realizarlo desde la documentación oficial de Wazuh:

- [https://documentation.wazuh.com/current/quickstart.html](https://documentation.wazuh.com/current/quickstart.html)

##### <span style="color: rgb(53, 152, 219);">Requisitos.</span>

##### <span style="color: rgb(53, 152, 219);">Hardware.</span>

Los requisitos de hardware dependen en gran medida de la cantidad de puntos finales protegidos y cargas de trabajo en la nube. Este número puede ayudar a estimar cuántos datos se analizarán y cuántas alertas de seguridad se almacenarán e indexarán.

La siguiente tabla muestra el hardware recomendado para una implementación:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/7wpwTmJpy7CtCGTR-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/7wpwTmJpy7CtCGTR-image.png)

##### <span style="color: rgb(53, 152, 219);">Compatibilidad del navegador.</span>

Se admiten los siguientes navegadores web:

- Chrome 95 o posterior
- Firefox 93 o posterior
- Safari 13.7 o posterior

Es posible La funcionalidad en navegadores basados ​​en Chromium.

#### **<span style="color: rgb(53, 152, 219);">Instalación rápida Wazuh Manager.</span>**

Ejecución del asistente de instalación de Wazuh.

```shell
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh && sudo bash ./wazuh-install.sh -a
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/O6Ta17ef6dywntAj-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/O6Ta17ef6dywntAj-image.png)

Una vez finalizada la instalación, el resultado muestra las credenciales de acceso y un mensaje que confirma que la instalación fue exitosa.

```
    INFO: --- Summary ---
    INFO: You can access the web interface https://<wazuh-dashboard-ip>
        User: admin
        Password: <CONTRASEÑA>
    INFO: Installation finished.
```

Instalación y configuración exitosa de Wazuh. Para acceder a la interfaz web de Wazuh se utiliza:  
https://&lt;wazuh-dashboard-ip&gt; (con las respectivas credenciales)

```
Nombre de usuario: admin
Contraseña: <CONTRASEÑA>
```

Cuando accede al panel de Wazuh por primera vez, el navegador muestra un mensaje de advertencia que indica que el certificado no fue emitido por una autoridad confiable. Esto es lo esperado y el usuario tiene la opción de aceptar el certificado como una excepción o, alternativamente, configurar el sistema para usar un certificado de una autoridad confiable.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/oZcdN69etyBfm8Yp-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/oZcdN69etyBfm8Yp-image.png)

##### Almacenamiento de contraseñas.  


Se puede encontrar las contraseñas de todos los usuarios del indexador de Wazuh y de la API de Wazuh en la página wazuh-passwords.txtarchivo dentro wazuh-install-files.tar.

Para imprimirlos, ejecute el siguiente comando:

```shell
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt
```

#### <span style="color: rgb(53, 152, 219);">**Instalación del agente de Wazuh.** </span>

En caso de no tener instalado el paquete 'curl' se debe proceder con la instalación del mismo para realizar la descarga de elementos.

```shell
sudo apt install curl
```

##### Instalación de claves GPG

```shell
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
```

##### Añadir el repositorio de Wazuh a las listas de repositorios.

```shell
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list
```

##### Actualizar la información de los paquetes.

```shell
apt-get update
```

##### **DESPLIEGUE DEL AGENTE.**

Se recomienda desplegar el agente de Wazuh desde el servidor en la web por la simplicidad de su ejecución.

Agregamos al nuevo agente:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/8CmhKASpd5nnvDdU-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/8CmhKASpd5nnvDdU-image.png)

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/oqql3JMMwj7c0ai4-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/oqql3JMMwj7c0ai4-image.png)

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/0lpiCdgYhilgEja7-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/0lpiCdgYhilgEja7-image.png)

Con el asistente tenemos los comandos a insertar en el terminal del nuevo agente por lo que procedemos a copiar los comandos generados:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/fowj8IArwcW00aq7-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/fowj8IArwcW00aq7-image.png)

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/eHIMV5Ms2u6O7YE4-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/eHIMV5Ms2u6O7YE4-image.png)

Actualizamos el navegador y tenemos al agente desplegado.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/gkoDdhLQq9MRU9a3-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/gkoDdhLQq9MRU9a3-image.png)

# Actualización Wazuh Manager

Para realizar la actualización del servidor de Wazuh procedemos a identificar la versión que tenemos. Se puede identificar desde el Dashboard haciendo clic en la parte superior derecha. Identificamos que tenemos la versión v 4.7.3.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-10/scaled-1680-/bathbOInSfoYjthC-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-10/bathbOInSfoYjthC-image.png)

En la página oficial de Wazuh se encuentra la documentación donde nos indican cuál es la versión actual en la esquina superior derecha, por lo que procedemos a verificar la última versión.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-10/scaled-1680-/obZyIA0OHFNSv6Ht-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-10/obZyIA0OHFNSv6Ht-image.png)

Se deben verificar las características de hardware necesarias para que no se tengan problemas de espacio en disco y cantidad de memoria RAM requerida.

Como los servicios de Indexador, Dashboard y Manager de Wazuh se encuentran en el mismo equipo, poseen la misma dirección IP y no se tiene configuración de cluster, se procede a detener estos servicios de Wazuh, con la respectiva verificación.

```shell
sudo systemctl stop wazuh-manager
sudo systemctl stop wazuh-dashboard
sudo systemctl stop wazuh-indexer
```

```shell
sudo systemctl status wazuh-manager
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/7yG5i9BZf9mVI8EB-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/7yG5i9BZf9mVI8EB-image.png)

```shell
sudo systemctl status wazuh-dashboard
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/W8GeNp6L6WLoPlpM-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/W8GeNp6L6WLoPlpM-image.png)

```shell
sudo systemctl status wazuh-indexer
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/nxkNhEaliq9Fjhhl-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/nxkNhEaliq9Fjhhl-image.png)

Posteriormente realizamos una actualización de los repositorios.

```shell
sudo apt-get update
```

Listamos los paquetes que pueden actualizarse para encontrar wazuh-dashboard, wazuh-indexer y wazuh-manager en la lista.

```shell
sudo apt list --upgradable
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/ttwZGKBQijAP7ryD-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/ttwZGKBQijAP7ryD-image.png)

Por ultimo realizamos la actualización de paquetes con el comando upgrade.

```shell
sudo apt upgrade
```

Durante la actualización de los componentes del sistema, se nos proporciona la opción de reemplazar archivos en la funcionalidad del dashboard con la siguiente consulta, en la cual debemos seleccionar la opción "D" para revisar los cambios implementados en los archivos de configuración.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-07/scaled-1680-/oXF4r4BdIQcXUgBH-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-07/oXF4r4BdIQcXUgBH-image.png)

```bash
Fichero de configuración /etc/wazuh-dashboard/opensearch_dashboards.yml'
 ==> Modificado (por usted o por un script) desde la instalación.
 ==> El distribuidor del paquete ha publicado una versión actualizada.
   ¿Qué quisiera hacer al respecto?  Sus opciones son:
    Y o I  : instalar la versión del desarrollador del paquete 
    N o O  : conservar la versión que tiene instalada actualmente
      D    : mostrar las diferencias entre versiones
      Z    : ejecutar un intérprete de órdenes para examinar la situación
 La acción por omisión es conservar la versión actual.
*** opensearch_dashboards.yml (Y/I/N/O/D/Z) [por omisión=N] ? D
--- /etc/wazuh-dashboard/opensearch_dashboards.yml      2024-08-01 20:39:58.576766390 +0000
+++ /etc/wazuh-dashboard/opensearch_dashboards.yml.dpkg-new     2023-05-05 12:31:50.000000000 +0000
@@ -1,15 +1,14 @@
 server.host: 0.0.0.0
-opensearch.hosts: https://127.0.0.1:9200
 server.port: 443
+opensearch.hosts: https://localhost:9200
 opensearch.ssl.verificationMode: certificate
-# opensearch.username: kibanaserver
-# opensearch.password: kibanaserver
+#opensearch.username:
+#opensearch.password:
 opensearch.requestHeadersAllowlist: ["securitytenant","Authorization"]
 opensearch_security.multitenancy.enabled: false
 opensearch_security.readonly_mode.roles: ["kibana_read_only"]
 server.ssl.enabled: true
-server.ssl.key: "/etc/wazuh-dashboard/certs/wazuh-dashboard-key.pem"
-server.ssl.certificate: "/etc/wazuh-dashboard/certs/wazuh-dashboard.pem"
+server.ssl.key: "/etc/wazuh-dashboard/certs/dashboard-key.pem"
+server.ssl.certificate: "/etc/wazuh-dashboard/certs/dashboard.pem"
 opensearch.ssl.certificateAuthorities: ["/etc/wazuh-dashboard/certs/root-ca.pem"]
-uiSettings.overrides.defaultRoute: /app/wazuh
-opensearch_security.cookie.secure: true
+uiSettings.overrides.defaultRoute: /app/wz-home
```

El mismo caso se presenta multiples veces en la instalación de Wazuh Indexer por lo que seleccionamos la misma opción "D" para revisar los cambios que se realizan en nuestros archivos de configuración:

```bash
--- /etc/init.d/wazuh-indexer   1970-01-01 00:00:00.000000000 +0000
+++ /etc/init.d/wazuh-indexer.dpkg-new  2024-08-30 10:12:22.000000000 +0000
@@ -0,0 +1,168 @@
+#!/usr/bin/env bash
+#
+# /etc/init.d/wazuh-indexer -- startup script for Wazuh indexer
+#
+### BEGIN INIT INFO
+# Provides:          wazuh-indexer
+# Required-Start:    $network $remote_fs $named
+# Required-Stop:     $network $remote_fs $named
+# Default-Start:     2 3 4 5
+# Default-Stop:      0 1 6
+# Short-Description: Starts wazuh-indexer
+# Description:       Starts wazuh-indexer using start-stop-daemon
+### END INIT INFO
+set -e -o pipefail
+PATH=/bin:/usr/bin:/sbin:/usr/sbin
+NAME=wazuh-indexer
+DESC=$NAME
+DEFAULT=/etc/default/$NAME
+
+if [ `id -u` -ne 0 ]; then
+       echo "You need root privileges to run this script"
+       exit 1
+fi
+
+. /lib/lsb/init-functions
+
+if [ -r /etc/default/rcS ]; then
+       . /etc/default/rcS
+fi
+
+# The following variables can be overwritten in $DEFAULT
+
+# Directory where the OpenSearch binary distribution resides
+OPENSEARCH_HOME=/usr/share/$NAME
+
+# Additional Java OPTS
+#OPENSEARCH_JAVA_OPTS=
+
+# Maximum number of open files
+MAX_OPEN_FILES=65535
+
+# Maximum amount of locked memory
+#MAX_LOCKED_MEMORY=
+
+# OpenSearch configuration directory
+OPENSEARCH_PATH_CONF=/etc/$NAME
+
+# Maximum number of VMA (Virtual Memory Areas) a process can own
+MAX_MAP_COUNT=262144
+
+# OpenSearch PID file directory
+PID_DIR="/var/run/$NAME"
+
+# End of variables that can be overwritten in $DEFAULT
+
+# overwrite settings from default file
+if [ -f "$DEFAULT" ]; then
+       . "$DEFAULT"
+fi
+
+# Define other required variables
+PID_FILE="$PID_DIR/$NAME.pid"
+DAEMON=$OPENSEARCH_HOME/bin/opensearch
+DAEMON_OPTS="-d -p $PID_FILE"
+
+export OPENSEARCH_JAVA_OPTS
+export OPENSEARCH_PATH_CONF
+export JAVA_HOME
+export OPENSEARCH_JAVA_HOME
+
+if [ ! -x "$DAEMON" ]; then
+       echo "The wazuh-indexer startup script does not exists or it is not executable, tried: $DAEMON"
+       exit 1
+fi
+
+case "$1" in
+  start)
+
+       log_daemon_msg "Starting $DESC"
+
+       pid=`pidofproc -p $PID_FILE wazuh-indexer`
+       if [ -n "$pid" ] ; then
+               log_begin_msg "Already running."
+               log_end_msg 0
+               exit 0
+       fi
+
+       # Ensure that the PID_DIR exists (it is cleaned at OS startup time)
+       if [ -n "$PID_DIR" ] && [ ! -e "$PID_DIR" ]; then
+               mkdir -p "$PID_DIR" && chown wazuh-indexer:wazuh-indexer "$PID_DIR"
+       fi
+       if [ -n "$PID_FILE" ] && [ ! -e "$PID_FILE" ]; then
+               touch "$PID_FILE" && chown wazuh-indexer:wazuh-indexer "$PID_FILE"
+       fi
+
+       if [ -n "$MAX_OPEN_FILES" ]; then
+               ulimit -n $MAX_OPEN_FILES
+       fi
+
+       if [ -n "$MAX_LOCKED_MEMORY" ]; then
+               ulimit -l $MAX_LOCKED_MEMORY
+       fi
+
+       if [ -n "$MAX_MAP_COUNT" -a -f /proc/sys/vm/max_map_count ] && [ "$MAX_MAP_COUNT" -gt $(cat /proc/sys/vm/m>
+               sysctl -q -w vm.max_map_count=$MAX_MAP_COUNT
+       fi
+
+       # Start Daemon
+       start-stop-daemon -d $OPENSEARCH_HOME --start --user wazuh-indexer -c wazuh-indexer --pidfile "$PID_FILE" >
+       return=$?
+       if [ $return -eq 0 ]; then
+               i=0
+               timeout=10
+               # Wait for the process to be properly started before exiting
+               until { kill -0 `cat "$PID_FILE"`; } >/dev/null 2>&1
+               do
+                       sleep 1
+                       i=$(($i + 1))
+                       if [ $i -gt $timeout ]; then
+                               log_end_msg 1
+                               exit 1
+                       fi
+               done
+       fi
+       log_end_msg $return
+       exit $return
+       ;;
+  stop)
+       log_daemon_msg "Stopping $DESC"
+
+       if [ -f "$PID_FILE" ]; then
+               start-stop-daemon --stop --pidfile "$PID_FILE" \
+                       --user wazuh-indexer \
+                       --quiet \
+                       --retry forever/TERM/20 > /dev/null
+               if [ $? -eq 1 ]; then
+                       log_progress_msg "$DESC is not running but pid file exists, cleaning up"
+               elif [ $? -eq 3 ]; then
+                       PID="`cat $PID_FILE`"
+                       log_failure_msg "Failed to stop $DESC (pid $PID)"
+                       exit 1
+               fi
+               rm -f "$PID_FILE"
+       else
+               log_progress_msg "(not running)"
+       fi
+       log_end_msg 0
+       ;;
+  status)
+       status_of_proc -p $PID_FILE wazuh-indexer wazuh-indexer && exit 0 || exit $?
+       ;;
+  restart|force-reload)
+       if [ -f "$PID_FILE" ]; then
+               $0 stop
+       fi
+       $0 start
+       ;;
+  *)
+       log_success_msg "Usage: $0 {start|stop|restart|force-reload|status}"
+       exit 1
+       ;;
+esac
+
+exit 0
```

```bash
--- /etc/wazuh-indexer/jvm.options      2024-08-01 20:37:13.516578584 +0000
+++ /etc/wazuh-indexer/jvm.options.dpkg-new     2024-08-30 10:14:23.000000000 +0000
@@ -19,8 +19,8 @@
 # Xms represents the initial size of total heap space
 # Xmx represents the maximum size of total heap space
 
--Xms1955m
--Xmx1955m
+-Xms1g
+-Xmx1g
 
 ################################################################
 ## Expert settings
@@ -79,13 +79,15 @@
 # Explicitly allow security manager (https://bugs.openjdk.java.net/browse/JDK-8270380)
 18-:-Djava.security.manager=allow
 
+# JDK 20+ Incubating Vector Module for SIMD optimizations;
+# disabling may reduce performance on vector optimized lucene
+20:--add-modules=jdk.incubator.vector
+
+# HDFS ForkJoinPool.common() support by SecurityManager
+-Djava.util.concurrent.ForkJoinPool.common.threadFactory=org.opensearch.secure_sm.SecuredForkJoinWorkerThreadFact>
+
 ## OpenSearch Performance Analyzer
 -Dclk.tck=100
 -Djdk.attach.allowAttachSelf=true
 -Djava.security.policy=file:///etc/wazuh-indexer/opensearch-performance-analyzer/opensearch_security.policy
---add-opens=jdk.attach/sun.tools.attach=ALL-UNNAMED
-
-## OpenDistro Performance Analyzer
--Dclk.tck=100
--Djdk.attach.allowAttachSelf=true
--Djava.security.policy=file:///usr/share/wazuh-indexer/plugins/opendistro-performance-analyzer/pa_config/es_secur>
+--add-opens=jdk.attach/sun.tools.attach=ALL-UNNAMED
\ No newline at end of file

```

```bash
--- /etc/wazuh-indexer/opensearch-security/internal_users.yml   2024-08-01 20:40:06.324974273 +0000
+++ /etc/wazuh-indexer/opensearch-security/internal_users.yml.dpkg-new  2024-08-30 10:14:23.000000000 +0000
@@ -1,19 +1,36 @@
 ---
+# This is the internal user database
+# The hash value is a bcrypt hash and can be generated with plugin/tools/hash.sh
+
 _meta:
   type: "internalusers"
   config_version: 2
+
+# Define your internal users here
+
+## Demo users
+
 admin:
-  hash: $2y$12$Cu8jP7gd1mJlSClvW82kCO69/S7Yf74IGdY9bPWcTeHjwoH0uYr6q
+  hash: "$2a$12$VcCDgh2NDk07JGN0rjGbM.Ad41qVR/YFJcgHp0UGns5JDymv..TOG"
   reserved: true
   backend_roles:
   - "admin"
   description: "Demo admin user"
+
+anomalyadmin:
+  hash: "$2y$12$TRwAAJgnNo67w3rVUz4FIeLx9Dy/llB79zf9I15CKJ9vkM4ZzAd3."
+  reserved: false
+  opendistro_security_roles:
+  - "anomaly_full_access"
+  description: "Demo anomaly admin user, using internal role"
+
 kibanaserver:
-  hash: $2y$12$kr4ikvWjGejjmlMnz6wTJ.sIYy6lR9uEy1ljW1l3w8eJMBrNwFd7S
+  hash: "$2a$12$4AcgAt3xwOWadA5s5blL6ev39OXDNhmOesEoo33eZtrq2N0YrU3H."
   reserved: true
-  description: "Demo kibanaserver user"
+  description: "Demo OpenSearch Dashboards user"
+
 kibanaro:
-  hash: $2y$12$/nkeD10mgx3qKoD7W6kWwO7WCMPmsS/pgHj0S3GhiYhzgeCS5JJHu
+  hash: "$2a$12$JJSXNfTowz7Uu5ttXfeYpeYE0arACvcwlPBStB1F.MI7f0U9Z4DGC"
   reserved: false
   backend_roles:
   - "kibanauser"
@@ -22,22 +39,25 @@
     attribute1: "value1"
     attribute2: "value2"
     attribute3: "value3"
-  description: "Demo kibanaro user"
+  description: "Demo read only user, using external role mapping"
+
 logstash:
-  hash: $2y$12$Z7sPb.rL8/MGxz7jtXdbFOoURmtGIW/G4vLjA.96M8wH8y.4FLTUu
+  hash: "$2a$12$u1ShR4l4uBS3Uv59Pa2y5.1uQuZBrZtmNfqB3iM/.jL0XoV9sghS2"
   reserved: false
   backend_roles:
   - "logstash"
-  description: "Demo logstash user"
+  description: "Demo logstash user, using external role mapping"
+
 readall:
-  hash: $2y$12$T0fcXbC8L/fut/BLGV5/7uSleSxKlrX53LjWEX4mZ9XNlaYhWzSkC
+  hash: "$2a$12$ae4ycwzwvLtZxwZ82RmiEunBbIPiAmGZduBAjKN0TXdwQFtCwARz2"
   reserved: false
   backend_roles:
   - "readall"
-  description: "Demo readall user"
+  description: "Demo readall user, using external role mapping"
+
 snapshotrestore:
-  hash: $2y$12$sS6Ecv.XpRDuB6Xw1N7OCu8ubT1xB5uKnIMtqzi32ZyD98IotSqXW
+  hash: "$2y$12$DpwmetHKwgYnorbgdvORCenv4NAK8cPUg8AI6pxLCuWf/ALc0.v7W"
   reserved: false
   backend_roles:
   - "snapshotrestore"
-  description: "Demo snapshotrestore user"
+  description: "Demo snapshotrestore user, using external role mapping"

```

Modificamos el nombre de los certificados de Wazuh dashboard para que estén de acuerdo a la nueva configuración.

```shell
sudo mv /etc/wazuh-dashboard/certs/wazuh-dashboard-key.pem /etc/wazuh-dashboard/certs/dashboard-key.pem
sudo mv /etc/wazuh-dashboard/certs/wazuh-dashboard.pem /etc/wazuh-dashboard/certs/dashboard.pem
```

Cambiamos la lista de permisos.

```shell
sudo chown wazuh-dashboard:wazuh-dashboard /etc/wazuh-dashboard/certs/*.pem
sudo chmod 600 /etc/wazuh-dashboard/certs/*.pem
```

Verificamos la configuración de la API por el puerto "55000".

```shell
sudo nano /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml
```

```bash
hosts:
  - default:
      url: https://127.0.0.1
      port: 55000
      username: wazuh-wui
      password: "Contraseña Wazuh-Wui"
      run_as: false
```

Por último para la cantidad de memoria RAM asignada para los procesos modificamos el archivo:

```shell
sudo nano /etc/wazuh-indexer/jvm.options
```

Dentro del archivo cambiamos "Xms1g" por "Xms2g"

En el caso de la modificación de permisos por actualizar desde una versión inferior a 4.5.7 se vuelve a modificar el cambio de directorio del indexador.

```shell
sudo chmod -R 755 /usr/share/wazuh-indexer
sudo chown -R wazuh-indexer:wazuh-indexer /usr/share/wazuh-indexer
```

Realizamos un "**restart**" a cada uno de los componentes de Wazuh para aplicar los cambios y esperamos aproximadamente 2 minutos para utilizar los servicios.

```shell
sudo systemctl daemon-reload
sudo systemctl restart wazuh-manager
sudo systemctl restart wazuh-dashboard
sudo systemctl restart wazuh-indexer
```

```shell
sudo systemctl status wazuh-manager
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/nd3ucBoKUl5z0JKq-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/nd3ucBoKUl5z0JKq-image.png)

```shell
sudo systemctl status wazuh-dashboard
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/jKn8DbZbvHvI7sqa-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/jKn8DbZbvHvI7sqa-image.png)

```shell
sudo systemctl status wazuh-indexer
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/UW2X6CnPFFTRrwiG-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/UW2X6CnPFFTRrwiG-image.png)

En el caso del sistema Ubuntu server 22.04 en fecha 03-10-2024, se normalizó la utilización de la herramienta después de un reinicio y una espera de 5 minutos.

```shell
sudo reboot
```

Ingresamos al dashboard y verificamos que la versión de Wazuh se actualizó con éxito.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-10/scaled-1680-/uLhVGgvltZiX1djr-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-10/uLhVGgvltZiX1djr-image.png)

Consideraciones a tomar en cuenta en caso de más de 50 agentes de Wazuh.

```shell
nano /etc/wazuh-indexer/jvm.options
```

Expandir la cantidad de recursos que se pueden utilizar en caso de exceso de eventos e incrementar según consumo de recursos Ej. a 2GB para indexación de elementos.

```bash
# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space
-Xms2048m
-Xmx2048m
```

# Pruebas de concepto (PDC)

### <span style="color: rgb(53, 152, 219);">PDC 1: BLOQUEO DE DIRECCIÓN IP MALICIOSA CONOCIDA.</span>

Se configurará servidor web Apache en Ubuntu y se intenta acceder a ellos desde un terminal Debian que simulara a un atacante con una IP con baja reputación en listas de IP maliciosas.

<table border="1" id="bkmrk-terminal-descripci%C3%93n" style="border-collapse: collapse; width: 97.284%; height: 169px;"><colgroup><col style="width: 21.2759%;"></col><col style="width: 78.8813%;"></col></colgroup><tbody><tr style="height: 34.1667px;"><td class="align-center" style="height: 34.1667px;"><span style="color: rgb(53, 152, 219);">***TERMINAL***</span>  
</td><td class="align-center" style="height: 34.1667px;"><span style="color: rgb(53, 152, 219);">***DESCRIPCIÓN***</span>

</td></tr><tr style="height: 63.1667px;"><td style="height: 63.1667px;"><span style="color: rgb(53, 152, 219);">***Debian***</span></td><td style="height: 63.1667px;">Terminal del atacante que se conecta al servidor web de la víctima en el que usa la capacidad de la lista CDB de Wazuh para marcar su dirección IP como maliciosa.</td></tr><tr style="height: 79.9667px;"><td style="height: 79.9667px;"><span style="color: rgb(53, 152, 219);">***Ubuntu***</span></td><td class="align-left" style="height: 79.9667px;">Terminal de la víctima que ejecuta un servidor web Apache 2.4.54. Se utiliza el módulo de respuesta activa de Wazuh para bloquear automáticamente las conexiones desde el terminal del atacante.</td></tr></tbody></table>

#### <span style="color: rgb(53, 152, 219);">Configuración.</span>

En Wazuh Manager.

Se debe agregar la dirección IP del extremo de Debian a una lista negra de usuarios peligrosos para la red y luego configurar las reglas y la respuesta activa.

En la guía de procedimientos de prueba de Wazuh manager se encuentran pasos de instalación del comando:

```shell
sudo apt update && sudo apt install -y wget
```

Descargue la base de datos de reputación de IP de Alienvault:

```shell
sudo wget https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/alienvault_reputation.ipset -O /var/ossec/etc/lists/alienvault_reputation.ipset
```

Agregamos la dirección IP del extremo del atacante (Debian) a la base de datos de reputación de IP. La dirección IP de Debian en el ejemplo es (192.168.24.73).

```shell
sudo echo 192.168.24.73 >> /var/ossec/etc/lists/alienvault_reputation.ipset
```

Descargamos el siguiente script para convertir del formato “.ipset” (formato utilizado para crear conjuntos de direcciones IP que se pueden usar como tablas para comparación) al formato “.cdb” (formato de lista que utiliza wazuh enlistar las direcciones maliciosas para su posterior bloqueo).

```shell
sudo wget https://wazuh.com/resources/iplist-to-cdblist.py -O /tmp/iplist-to-cdblist.py
```

Convertimos el archivo “alienvault\_reputation.ipset” a un formato “.cdb” usando el script descargado previamente:

```shell
sudo /var/ossec/framework/python/bin/python3 /tmp/iplist-to-cdblist.py /var/ossec/etc/lists/alienvault_reputation.ipset /var/ossec/etc/lists/blacklist-alienvault
```

Eliminamos “alienvault\_reputation.ipset” y el script “iplist-to-cdblist.py”, para que no sean usados erronea o de forma maliciosa.

```shell
sudo rm -rf /var/ossec/etc/lists/alienvault_reputation.ipset
sudo rm -rf /tmp/iplist-to-cdblist.py
```

Asignamos los permisos y la propiedad correctos al archivo generado:

```shell
sudo chown wazuh:wazuh /var/ossec/etc/lists/blacklist-alienvault
```

La siguiente regla personalizada se utiliza para para activar una secuencia de comandos de respuesta activa de Wazuh cuando se detecte un evento en el cual se haya reconocido una dirección IP maliciosa realizando intercambio de información con puntos finales monitoreados por Wazuh manager, para esto ingresamos al archivo de reglas personalizadas de Wazuh.

```shell
sudo nano /var/ossec/etc/rules/local_rules.xml
```

En el archivo de conjunto de reglas personalizado del servidor Wazuh:

```xml
<group name="attack,">
  <rule id="100100" level="11">
    <if_group>web|attack|attacks</if_group>
    <list field="srcip" lookup="address_match_key">etc/lists/blacklist-alienvault</list>
    <description>IP address found in AlienVault reputation database.</description>
  </rule>
</group>
```

Editamos el archivo de configuración del servidor Wazuh.

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

Para que se pueda comparar con la lista de direcciones de alienvault agregamos la lista creada “etc/lists/blacklist-alienvault” a la sección “&lt;ruleset&gt;”.

```xml
<ossec_config>
  <ruleset>
    <!-- Default ruleset -->
    <decoder_dir>ruleset/decoders</decoder_dir>
    <rule_dir>ruleset/rules</rule_dir>
    <rule_exclude>0215-policy_rules.xml</rule_exclude>
    <list>etc/lists/audit-keys</list>
    <list>etc/lists/amazon/aws-eventnames</list>
    <list>etc/lists/security-eventchannel</list>
    <list>etc/lists/blacklist-alienvault</list>
    <!-- User-defined ruleset -->
    <decoder_dir>etc/decoders</decoder_dir>
    <rule_dir>etc/rules</rule_dir>
  </ruleset>
</ossec_config>
```

Agrega una respuesta activa al wazuh manager (con permisos de root):

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

Se debe quitar el símbolo de comentario al apartado &lt;active-response&gt; y escribir de acuerdo al ID de la regla creada en este caso 100100.

```xml
  <active-response>
        <command>firewall-drop</command>
        <location>local</location>
        <rules_id>100100</rules_id>
  </active-response>
```

En el terminal víctima.

Se instala un servidor web con Apache para las pruebas, este tendrá un agente que constantemente está realizando el monitoreo de los registros de acceso del servidor Apache.

Configuramos el agente de Wazuh:

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

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/apache2/access.log</location>
</localfile>
```

#### <span style="color: rgb(53, 152, 219);">Emulación del ataque.  
</span>

Para la emulación de ataque se debe acceder al servidor web desde el extremo Kali utilizando la dirección IP correspondiente:

Ya sea desde el navegador o desde la consola:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/Ksk5fZXaPXit0kSZ-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/Ksk5fZXaPXit0kSZ-image.png)Wazuh manager identificara la dirección IP de conexión para ser analizada y al coincidir con la dirección IP de la base de datos de reputación enviara la alerta para activar la respuesta inmediata bloqueando la dirección IP con el número de ID de alerta 100100 que es el creado manualmente para el servidor.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/e4gPk0DOoliM5KiU-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/e4gPk0DOoliM5KiU-image.png)

#### <span style="color: rgb(53, 152, 219);">Resultados.</span>

<span style="color: rgb(0, 0, 0);">Posteriormente Wazuh manager bloquea el intento de acceso y el servidor se hace inaccesible por parte del atacante.</span>

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/pEmntNTj42dIa5Jz-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/pEmntNTj42dIa5Jz-image.png)

### <span style="color: rgb(53, 152, 219);">PDC 2: MONITOREO DE INTEGRIDAD DE ARCHIVOS.</span>

Wazuh tiene un módulo FIM (File Integrity Monitoring) el cual es un proceso de seguridad que se utiliza para monitorear la integridad de los archivos del sistema se revisan los cambios en el sistema de archivos para detectar la creación, modificación y eliminación de archivos.

#### <span style="color: rgb(53, 152, 219);">Configuración.</span>

Para esta prueba utilizaremos Debian, el módulo FIM de Wazuh supervisa un directorio (/root) para detectar la creación, los cambios y la eliminación de archivos.

Se debe editar el archivo de configuración agregando dentro del bloque &lt;syscheck&gt; directorios para ser monitoreados (se puede configurar cualquier ruta en específico).

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

```xml
<directories check_all="yes" report_changes="yes" realtime="yes">/root</directories>
```

Reiniciamos para aplicar los cambios.

```shell
sudo systemctl restart wazuh-agent
```

#### <span style="color: rgb(53, 152, 219);">Emulación del ataque.</span>

En el ámbito de la seguridad informática existen directorios que no deben ser modificados ya que contienen configuraciones para el funcionamiento correcto de los programas ó en su defecto la copia de archivos maliciosos que contienen malware, por lo cual la prueba consiste en crear un archivo de texto en el directorio monitoreado.

```shell
cd /root/
touch archivo.txt
```

Agregue contenido al archivo de texto y guárdelo.

```shell
echo "contenido de archivo" >> archivo.txt
```

Elimine el archivo de texto del directorio supervisado.

```shell
rm archivo.txt
```

#### <span style="color: rgb(53, 152, 219);">Resultados.</span>

Con la creación del archivo se genera una alerta de nivel 3 ya que el archivo esta vacío.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/wkWRqrRIC2KsoyfU-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/wkWRqrRIC2KsoyfU-image.png)

La modificación del archivo genera una alerta de nivel 8 al ser un directorio importante para ser monitorizado.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/dHmdaMopmJvwm3xy-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/dHmdaMopmJvwm3xy-image.png)

Por ultimo se genera la alerta de eliminación del archivo de nivel 7.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/AkLDdYI4vvwrgXeT-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/AkLDdYI4vvwrgXeT-image.png)

### <span style="color: rgb(53, 152, 219);">PDC 3: ATAQUE DE FUERZA BRUTA.</span>

<table border="1" id="bkmrk-terminal-descripci%C3%93n-1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 16.0968%;"></col><col style="width: 83.998%;"></col></colgroup><tbody><tr><td class="align-center">TERMINAL  
</td><td class="align-center">DESCRIPCIÓN

</td></tr><tr><td>Debian  
</td><td>Terminal del atacante que realiza ataques de fuerza bruta. Con SSH instalado.</td></tr><tr><td>Ubuntu  
</td><td>Terminal víctima de ataques de fuerza bruta SSH. Es necesario tener un servidor SSH instalado y habilitado en este punto final.</td></tr></tbody></table>

#### <span style="color: rgb(53, 152, 219);">Configuración:</span>

Realice los siguientes pasos para configurar el terminal de Debian. Esto permite realizar intentos de falla de autenticación en la víctima Ubuntu.

En Debian instalar Hydra para utilizar un ataque de fuerza bruta mediante el protocolo ssh.

```shell
sudo apt update
sudo apt install -y hydra
```

#### <span style="color: rgb(53, 152, 219);">Emulación del ataque</span>

Crearemos un archivo de texto con 10 o más contraseñas aleatorias, esto simulara un diccionario de contraseñas de los cuales existen en la red que puede contener millones de contraseñas frecuentes para romper la seguridad mediante fuerza bruta.

```shell
sudo nano PASSWD_LIST.txt
```

```
123456
Password
Passwd
123
Root
Admin
Admin123
Root123
Server
Linux 
```

Guardamos este archivo como nuestro diccionario limitado de contraseñas y configuramos el terminal victima con una de estas contraseñas inseguras.

Por último ejecutamos "Hydra" desde el terminal atacante para realizar ataques de fuerza bruta contra el extremo de la víctima.

La sintaxis del comando es la siguiente tomando en cuenta **xubuntu** como nombre de usuario, PASSWD\_LIST.txt como el diccionario de contraseñas, **192.168.24.72** la direccion IP de la víctima y por ultimo el protocolo de acceso que será **ssh**.

```shell
sudo hydra -l xubuntu -P PASSWD_LIST.txt 192.168.24.72 ssh
```

#### <span style="color: rgb(53, 152, 219);">Resultados.</span>

Visualización de las alertas en Wazuh manager:  
Se pueden visualizar los datos de alerta en el panel de control de Wazuh, se debe acceder al módulo Eventos de seguridad para consultar las alertas.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/DkddmCbRSpMcagaD-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/DkddmCbRSpMcagaD-image.png)

### <span style="color: rgb(53, 152, 219);">PDC 4: DETECCIÓN DE PROCESOS NO AUTORIZADOS.  
</span>

En este caso de uso, utiliza la capacidad de monitoreo de comandos de Wazuh para detectar cuándo se está ejecutando Netcat en un punto final (Netcat es una utilidad de red informática que se utiliza para escanear y escuchar puertos).

En el terminal víctima modificamos el modulo de monitoreo desde el agente de Wazuh, de esta forma podremos detectar un proceso de Netcat en ejecución.

#### <span style="color: rgb(53, 152, 219);">Configuración.</span>

Agregamos la siguiente configuración al archivo de configuración del agente de Wazuh. Nos permite obtener periódicamente una lista de procesos en ejecución:

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

```xml
<ossec_config>
  <localfile>
    <log_format>full_command</log_format>
    <alias>process list</alias>
    <command>ps -e -o pid,uname,command</command>
    <frequency>30</frequency>
  </localfile>
</ossec_config>
```

Reiniciar el wazuh-agent para aplicar los cambios.

```shell
sudo systemctl restart wazuh-agent
```

Posteriormente instalamos Netcat para realizar las pruebas.

```shell
sudo apt install ncat nmap -y
```

Servidor de Wazuh.

Se configuran los siguientes pasos para crear una regla que se active cada vez que se inicie el programa Netcat.  
Agregando las siguientes reglas al archivo local de reglas en el servidor:

```shell
sudo nano /var/ossec/etc/rules/local_rules.xml
```

```xml
<group name="ossec,">
  <rule id="100050" level="0">
    <if_sid>530</if_sid>
    <match>^ossec: output: 'process list'</match>
    <description>Lista de procesos en ejecución </description>
    <group>process_monitor,</group>
  </rule>
  <rule id="100051" level="7" ignore="900">
    <if_sid>100050</if_sid>
    <match>nc -l</match>
    <description>netcat esta escuchando las conexiones entrantes.</description>
    <group>process_monitor,</group>
  </rule>
</group>
```

Reiniciamos el servidor para aplicar cambios.

```shell
sudo systemctl restart wazuh-manager
```

#### <span style="color: rgb(53, 152, 219);">Emulación de ataque.</span>

<span style="color: rgb(0, 0, 0);">Ejecutamos en el terminal el siguiente comando durante aproximadamente 30 segundos.</span>

```shell
nc -l 8000
```

<span style="color: rgb(0, 0, 0);">Este comando utiliza para crear un servidor en el **puerto 8000**, **-l** indica que el comando debe escuchar en lugar de conectarse a un puerto. El servidor creado escuchará en el puerto 8000 y esperará conexiones entrantes. Si se recibe una conexión, el comando nc enviará los datos recibidos a la salida estándar.</span>

#### <span style="color: rgb(53, 152, 219);">Resultados.</span>

<span style="color: rgb(0, 0, 0);">El servidor de Wazuh manager nos mostrara el siguiente evento:</span>

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/dWOk7SWlJGtRxH3V-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/dWOk7SWlJGtRxH3V-image.png)

### <span style="color: rgb(53, 152, 219);">PDC 5:INTEGRACIÓN DE IDS DE RED.</span>

<span style="color: rgb(0, 0, 0);">La integración de Suricata con Wazuh mejora la detección y respuesta a las amenazas en los sistemas monitoreados.  
Para esta prueba utilizaremos Debian donde se instalara Suricata, con esta integración se analiza el trafico de red generado en este terminal.</span>

#### <span style="color: rgb(53, 152, 219);">Configuración</span>

<span style="color: rgb(0, 0, 0);">Realizamos la instalación de Suricata en Debian.</span>

```shell
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt-get update
sudo apt-get install suricata -y
```

<span style="color: rgb(0, 0, 0);">Seguidamente descargamos y extraemos el conjunto de reglas de *Emerging Threats* *Suricata* el cual es un conjunto de reglas de detección de intrusiones que se utiliza para monitorear el tráfico de red en busca de cualquier actividad maliciosa, violaciones de políticas y amenazas que hará mas completo el monitoreo de este terminal.</span>

```shell
cd /tmp/ && curl -LO https://rules.emergingthreats.net/open/suricata-6.0.8/emerging.rules.tar.gz
sudo tar -xvzf emerging.rules.tar.gz && sudo mv rules/*.rules /etc/suricata/rules/
sudo chmod 640 /etc/suricata/rules/*.rules
```

<span style="color: rgb(0, 0, 0);">Una vez extraídos se debe modificar la configuración en el archivo “.yaml”</span>

```shell
sudo nano /etc/suricata/suricata.yaml
```

```
HOME_NET: "192.168.24.87"
EXTERNAL_NET: "any"
default-rule-path: /etc/suricata/rules
rule-files:
- "*.rules"
# Global stats configuration
stats:
  enabled: no
# Linux high speed capture support
af-packet:
- interface: enp0s18
```

El nombre de la interface se obtiene con el comando:

```shell
ip address show
```

<span style="color: rgb(0, 0, 0);">Reiniciar el servicio de Suricata.</span>

```shell
sudo systemctl restart suricata
```

<span style="color: rgb(0, 0, 0);">Para que el agente de Wazuh pueda leer el archivo de registros de Suricata se debe configurar el ossec.conf.</span>

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

```xml
<ossec_config>
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>
</ossec_config>
```

<span style="color: rgb(0, 0, 0);">Para aplicar cambios se reinicia el agente de Wazuh.</span>

```shell
sudo systemctl restart wazuh-agent
```

#### <span style="color: rgb(53, 152, 219);">Emulación del ataque.</span>

Wazuh analiza automáticamente los datos de los logs que se encuentran en /var/log/suricata/eve.json y genera alertas relacionadas en el dashboard.

Hacemos una prueba de ping a la dirección IP del terminal Debian desde el servidor de Wazuh:

```shell
ping -c 20 192.168.24.87
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/eIxo57zOgNWxLdeD-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/eIxo57zOgNWxLdeD-image.png)

#### <span style="color: rgb(53, 152, 219);">Resultados.</span>

Se genera la alerta de Suricata que se resume en el dashboard de Wazuh-Manager como ICMP proveniente de la dirección IP del atacante.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/SSKrWg7GWD3NDyaL-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/SSKrWg7GWD3NDyaL-image.png)

### <span style="color: rgb(53, 152, 219);">PDC 6: DETECCIÓN DE INYECCIÓN SQL.</span>

<table border="1" id="bkmrk-terminal-descripci%C3%93n-2" style="border-collapse: collapse; width: 76.4198%; height: 90.1001px;"><colgroup><col style="width: 24.2205%;"></col><col style="width: 75.7507%;"></col></colgroup><tbody><tr style="height: 30.9667px;"><td class="align-center" style="height: 30.9667px;">**TERMINAL**  
</td><td class="align-center" style="height: 30.9667px;">**DESCRIPCIÓN**

</td></tr><tr style="height: 29.5667px;"><td style="height: 29.5667px;">Debian  
</td><td style="height: 29.5667px;">Terminal atacante con payload de inyección SQL  
</td></tr><tr style="height: 29.5667px;"><td style="height: 29.5667px;">Ubuntu  
</td><td style="height: 29.5667px;">Terminal víctima con servidor web Apache</td></tr></tbody></table>

#### <span style="color: rgb(53, 152, 219);">Configuración.</span>

En la víctima se debe realizar los siguientes pasos para instalar Apache y configurar el agente de Wazuh para monitorear los registros de Apache.

```shell
sudo apt update
sudo apt install apache2
```

Si el Firewall está habilitado, se debe modificar para permitir el acceso externo a los puertos web. Omita este paso si el Firewall está deshabilitado.

```shell
sudo ufw app list
sudo ufw allow 'Apache'
sudo ufw status
```

Verificar el estado del servicio Apache para ver que el servidor web se está ejecutando:

```shell
sudo systemctl status apache2
```

Utilizar en consola curl o en su defecto abrir http://&lt;UBUNTU\_IP&gt; -&gt; http://192.168.24.73 en un navegador para ver la página de inicio de Apache y verificar la ejecución:

```shell
curl http://<UBUNTU_IP>
```

En la parte del agente Wazuh agregue las siguientes líneas del archivo de configuración.

```shell
nano /var/ossec/etc/ossec.conf
```

El siguiente comando permite al agente de Wazuh monitorear los registros de acceso de su servidor Apache y enviar registros continuamente a Wazuh manager:

```xml
<ossec_config>
  <localfile>
    <log_format>apache</log_format>
    <location>/var/log/apache2/access.log</location>
  </localfile>
</ossec_config>
```

Reinicie Wazuh agent para aplicar los cambios de configuración:

```shell
sudo systemctl restart wazuh-agent
```

#### <span style="color: rgb(53, 152, 219);">Emulación del ataque.  
</span>

Utilice el siguiente comando con la dirección IP adecuada del servidor y ejecute el siguiente comando desde el extremo del atacante:

```shell
curl -XGET "http://IP_VICTIMA/users/?id=SELECT+*+FROM+users";
```

El payload contiene una consulta SQL donde el comando quiere realizar la selección de todas las filas y todas las columnas de la tabla llamada "users" que suele ser por defecto los usuarios que se usan para ingresar en un login cuando se configura por defecto.

#### <span style="color: rgb(53, 152, 219);">Resultados</span>.

El resultado generó una alerta de intento de inyección SQL.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/0GV5hdyIUvXDkycU-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/0GV5hdyIUvXDkycU-image.png)

### <span style="color: rgb(53, 152, 219);">PDC 7: DETECCIÓN DE SUSPICIOUS BINARIES.  
</span>

Detectar binarios sospechosos es una capacidad de seguridad que permite identificar código ejecutable que puede ser malicioso o anómalo en un punto final. En este caso de uso, demostramos cómo el módulo rootcheck de Wazuh puede detectar un sistema binario troyano en un extremo victima.

El exploit se realiza reemplazando el contenido de un binario legítimo con un código malicioso para engañar al punto final para que lo ejecute como el binario legítimo, el módulo rootcheck de Wazuh también busca procesos, puertos y archivos ocultos.  
Configuración.

#### <span style="color: rgb(53, 152, 219);">Configuración</span>.

De forma predeterminada, el módulo rootcheck de Wazuh está habilitado en el archivo de configuración del agente de Wazuh.  
Verifique el apartado &lt;rootcheck&gt; en el archivo de configuración del terminal monitoreado y asegurarse que la configuración este dada de la siguiente manera

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

```xml
<rootcheck>
    <disabled>no</disabled>
    <check_files>yes</check_files>
    <!-- Line for trojans detection -->
    <check_trojans>yes</check_trojans>
    <check_dev>yes</check_dev>
    <check_sys>yes</check_sys>
    <check_pids>yes</check_pids>
    <check_ports>yes</check_ports>
    <check_if>yes</check_if>
    <!-- Frequency that rootcheck is executed - every 12 hours -->
    <frequency>43200</frequency>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
    <skip_nfs>yes</skip_nfs>
</rootcheck>
```

#### <span style="color: rgb(53, 152, 219);">Emulación de ataque</span>.

Creamos una copia del sistema binario original con:

```shell
sudo cp -p /usr/bin/w /usr/bin/w.copy
```

Ejecute el comando

```shell
sudo chmod +x /usr/bin/w.copy
```

Este da permisos de ejecución a la copia creada.

Reemplace el sistema binario original /usr/bin/w con el siguiente script de shell

```shell
sudo tee /usr/bin/w << EOF
!/bin/bash
echo "`date` this is evil" > /tmp/trojan_created_file
echo 'test for /usr/bin/w trojaned file' >> /tmp/trojan_created_file
Now running original binary
/usr/bin/w.copy
EOF
```

Este cambio en el archivo original es otro método de un ciberatacante y tiene las siguientes posibles consecuencias:

- Manipulación del sistema: El script sobrescribe el archivo legítimo /usr/bin/w, lo que podría interrumpir su funcionalidad prevista.
- Creación de datos: Crea un archivo llamado /tmp/trojan\_created\_file que contiene mensajes sospechosos.
- Comportamiento desconocido: No se conoce el propósito completo del script ni sus acciones potenciales, lo que lo convierte en un riesgo de seguridad.

El análisis de rootcheck se ejecuta cada 12 horas de forma predeterminada por lo que se debe forzar un escaneo reiniciando el agente de Wazuh.

```shell
sudo systemctl restart wazuh-agent
```

#### <span style="color: rgb(53, 152, 219);">Resultados.</span>

Mientras tanto Wazuh manager nos da como resultado la siguiente respuesta:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/03XY0EZ3hzJ0Uf3Y-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/03XY0EZ3hzJ0Uf3Y-image.png)

Para restablecer nuestro las condiciones originales anteriores a la prueba de seguridad y evitar problemas de funcionamiento debemos realizar la operación inversa.

Abrir la terminal en el punto final donde reemplazó el binario original /usr/bin/w y elimine el script de shell que escribió en el binario original.

```shell
sudo rm /usr/bin/w
```

Se debe restaurar la copia del binario original.

```shell
sudo mv /usr/bin/w.copy /usr/bin/w
```

Por ultimo eliminar el archivo que creó el script de shell.

```shell
sudo rm /tmp/trojan_created_file
```

Verifique que el binario original funcione correctamente con el comando **w** los resultados serán los siguientes en caso de estar restablecido.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/k30EecbsdDlsv4F6-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/k30EecbsdDlsv4F6-image.png)

### <span style="color: rgb(53, 152, 219);">PDC 8: DETECCIÓN Y ELIMINACIÓN DE MALWARE MEDIANTE INTEGRACIÓN CON VIRUS TOTAL.  
</span>

Wazuh puede utilizar un modulo de monitoreo para supervisar la integridad de los archivos en este caso buscando cambios realizados y la API de Virus-Total. Para la integración de Wazuh con Virus-Total. Todas estas configuraciones se realizan en el servidor primeramente y luego se realizará la configuración del agente.

#### <span style="color: rgb(53, 152, 219);">Configuración</span>.

Agregue las siguientes reglas al archivo local de reglas.

```shell
sudo nano /var/ossec/etc/rules/local_rules.xml
```

```xml
<group name="syscheck,pci_dss_11.5,nist_800_53_SI.7,">
    <!-- Rules for Linux systems -->
    <rule id="100200" level="7">
        <if_sid>550</if_sid>
        <field name="file">/root</field>
        <description>File modified in /root directory.</description>
    </rule>
    <rule id="100201" level="7">
        <if_sid>554</if_sid>
        <field name="file">/root</field>
        <description>File added to /root directory.</description>
    </rule>
</group>
```

Añadir la sección dentro del archivo de configuración Ossec.

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

Se realiza la configuración en este archivo para habilitar la integración de Virustotal. Reemplazando con la clave API de VirusTotal (Para obtener api\_key se debe crear una cuenta en virustotal y seguir los pasos correspondientes para copiar la API gratuita que ofrece el sitio) permitiendo activar una consulta siempre que alguna de las reglas y se activan, la configuración se realiza dentro de &lt;ossec\_config&gt; &lt;/ossec\_config&gt;.

```xml
  <integration>
    <name>virustotal</name>
    <api_key>API_KEY</api_key>
    <rule_id>100200,100201</rule_id>
    <alert_format>json</alert_format>
  </integration>
```

Agregamos los siguientes bloques al archivo del servidor Wazuh permitiendo una respuesta activa y activa el script cuando VirusTotal marca un archivo como malicioso en el archivo /var/ossec/etc/ossec.confremove-threat.sh

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

```xml
<ossec_config>
  <command>
    <name>remove-threat</name>
    <executable>remove-threat.sh</executable>
    <timeout_allowed>no</timeout_allowed>
  </command>
  <active-response>
    <disabled>no</disabled>
    <command>remove-threat</command>
    <location>local</location>
    <rules_id>87105</rules_id>
  </active-response>
</ossec_config>
```

Agregar reglas al servidor de Wazuh /var/ossec/etc/rules/local\_rules.xml archivo para alertar sobre los resultados de la respuesta activa:

```shell
sudo nano /var/ossec/etc/rules/local_rules.xml
```

```xml
<group name="virustotal,">
  <rule id="100092" level="12">
    <if_sid>657</if_sid>
    <match>Successfully removed threat</match>
    <description>$(parameters.program) removed threat located at $(parameters.alert.data.virustotal.source.file)</description>
  </rule>
  <rule id="100093" level="12">
    <if_sid>657</if_sid>
    <match>Error removing threat</match>
    <description>Error removing threat located at $(parameters.alert.data.virustotal.source.file)</description>
  </rule>
</group>
```

Reiniciamos el administrador de Wazuh para aplicar los cambios realizados.

```shell
systemctl restart wazuh-manager
```

Para esta prueba de concepto la maquina vulnerable es Debian linux en la cual realizaremos las siguientes configuraciones:

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

Dentro del archivo de configuración &lt;disabled&gt; se establece en no, permitiendo que Wazuh FIM controle los cambios de directorio.

```xml
<syscheck>
  <disabled>no</disabled>
```

Agregar una entrada dentro del apartado **&lt;syscheck&gt;** para configurar un directorio para ser monitoreado casi en tiempo real. En este caso se está monitoreando el directorio /root.

```xml
<directories realtime="yes">/root</directories>
```

Instalar “**jq**” la cual es una utilidad que procesa la entrada JSON del script de respuesta activo.

```shell
sudo apt update
sudo apt -y install jq
```

Creamos en el directorio **/var/ossec/active-response/bin/remove-threat.sh** el cual es una secuencia de comandos de respuesta activa para eliminar archivos maliciosos del punto final monitoreado.

```bash
#!/bin/bash
LOCAL=`dirname $0`;
cd $LOCAL
cd ../
PWD=`pwd`
read INPUT_JSON
FILENAME=$(echo $INPUT_JSON | jq -r .parameters.alert.data.virustotal.source.file)
COMMAND=$(echo $INPUT_JSON | jq -r .command)
LOG_FILE="${PWD}/../logs/active-responses.log"
if [ ${COMMAND} = "add" ]
then
 # Send control message to execd
 printf '{"version":1,"origin":{"name":"remove-threat","module":"active-response"},"command":"check_keys", "parameters":{"keys":[]}}\n'
 read RESPONSE
 COMMAND2=$(echo $RESPONSE | jq -r .command)
 if [ ${COMMAND2} != "continue" ]
 then
  echo "`date '+%Y/%m/%d %H:%M:%S'` $0: $INPUT_JSON Remove threat active response aborted" >> ${LOG_FILE}
  exit 0;
 fi
fi
# Removing file
rm -f $FILENAME
if [ $? -eq 0 ]; then
 echo "`date '+%Y/%m/%d %H:%M:%S'` $0: $INPUT_JSON Successfully removed threat" >> ${LOG_FILE}
else
 echo "`date '+%Y/%m/%d %H:%M:%S'` $0: $INPUT_JSON Error removing threat" >> ${LOG_FILE}
fi
exit 0;
```

Cambiar la propiedad y permisos del archivo creado /var/ossec/active-response/bin/remove-threat.sh.

```shell
sudo chmod 750 /var/ossec/active-response/bin/remove-threat.sh
```

Cambiamos el propietario del archivo para que Wazuh pueda ejecutar el script en caso de alertas activas.

```shell
sudo chown root:wazuh /var/ossec/active-response/bin/remove-threat.sh
```

Para aplicar estos cambios reiniciamos el agente.

```shell
sudo systemctl restart wazuh-agent
```

#### <span style="color: rgb(53, 152, 219);">Emulación del ataque.</span>

Para descargar un archivo de prueba EICAR en Debian Linux desde la consola. Abrir una terminal y acceda al directorio **/root** donde se guardará el archivo de prueba y ejecute el comando de descarga, en este caso:

```shell
sudo cd /root
sudo curl -LO https://secure.eicar.org/eicar.com && ls -lah eicar.com
```

Esperamos que se complete la descarga y verificamos el archivo eicar.com en el directorio, este archivo no contiene malware real sin embargo se reconoce como un malware de prueba para Virus Total.

#### <span style="color: rgb(53, 152, 219);">Resultados.</span>

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/uKniLTSNXlA1b6Bp-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/uKniLTSNXlA1b6Bp-image.png)

Wazuh manager tiene los siguientes eventos de detección. El evento de respuesta activa nos indica que el archivo fue eliminado y puede verificarse en consola:

**[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/IJwzFBP1u89er4y2-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/IJwzFBP1u89er4y2-image.png)**

### <span style="color: rgb(53, 152, 219);">PDC 9: DETECCIÓN DE VULNERABILIDADES.  
</span>

Los agentes de Wazuh recopilan una lista de aplicaciones instaladas desde los terminales monitoreados y la envían periódicamente al servidor de Wazuh.

El servidor de Wazuh posee bases de datos SQLite que almacenan la lista enviada por los agentes, el servidor de Wazuh crea una base de datos de vulnerabilidad global a partir de repositorios **CVE** disponibles públicamente y utiliza esta base de datos para correlacionar esta información con los datos del listado de aplicaciones del agente.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/2yFHUPBiDV1pJYv7-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/2yFHUPBiDV1pJYv7-image.png)

La imagen muestra el flujo de trabajo de la detección de vulnerabilidades en Wazuh. El flujo de trabajo comienza con la recopilación de datos de los agentes de Wazuh. Estos datos pueden incluir registros, configuraciones de sistemas y resultados de escaneo de vulnerabilidades. Wazuh luego analiza estos datos en busca de posibles vulnerabilidades. Una vez que Wazuh ha identificado una vulnerabilidad, genera una alerta. Las alertas pueden ser enviadas a los usuarios por correo electrónico, mensaje de texto o notificación push.  
La detección de vulnerabilidades es una parte importante de la gestión de seguridad de la información. Al identificar y remediar las vulnerabilidades, las organizaciones pueden proteger sus sistemas de ataques cibernéticos, los pasos que sigue el diagrama son:

- Recopilación de datos: Wazuh recopila datos de los agentes de Wazuh. Estos datos pueden incluir registros, configuraciones de sistemas y resultados de escaneo de vulnerabilidades.
- Análisis de datos: Wazuh analiza los datos recopilados en busca de posibles vulnerabilidades. Wazuh utiliza una variedad de métodos para analizar los datos, incluyendo reglas, firmas y aprendizaje automático.
- Generación de alertas: Una vez que Wazuh ha identificado una vulnerabilidad, genera una alerta. Las alertas pueden ser enviadas a los usuarios por correo electrónico, mensaje de texto o notificación push.
- Mitigación de vulnerabilidades: Los usuarios pueden utilizar la información proporcionada en las alertas de Wazuh para remediar las vulnerabilidades en sus sistemas.

#### <span style="color: rgb(53, 152, 219);">Configuración.</span>

<span style="color: rgb(0, 0, 0);">Nos dirigimos al directorio /var/ossec/etc/ossec.conf para realizar las siguientes modificaciones, dentro del apartado "`<ossec_config>`"  
</span>

```xml
  <vulnerability-detector>
    <enabled>yes</enabled>
    <interval>5m</interval>
    <min_full_scan_interval>6h</min_full_scan_interval>
    <run_on_start>yes</run_on_start>
    <!--         Ubuntu OS vulnerabilities -->
    <provider name="canonical">
    <enabled>yes</enabled>
    <os>trusty</os>
    <os>xenial</os>
    <os>bionic</os>
    <os>focal</os>
    <os>jammy</os>
    <update_interval>1h</update_interval>
    </provider>
    <!--         Debian OS vulnerabilities -->
    <provider name="debian">
    <enabled>yes</enabled>
    <os>buster</os>
    <os>bullseye</os>
    <update_interval>1h</update_interval>
    </provider>
    <!--         RedHat OS vulnerabilities -->
    <provider name="redhat">
    <enabled>yes</enabled>
    <os>5</os>
    <os>6</os>
    <os>7</os>
    <os>8</os>
    <os allow="CentOS Linux-8">8</os>
    <os>9</os>
    <update_interval>1h</update_interval>
    </provider>
    <!--         Windows OS vulnerabilities -->
    <provider name="msu">
    <enabled>yes</enabled>
    <update_interval>1h</update_interval>
    </provider>
    <!--         Aggregate vulnerabilities -->
    <provider name="nvd">
    <enabled>yes</enabled>
    <update_from_year>2019</update_from_year>
    <update_interval>1h</update_interval>
    </provider>
  </vulnerability-detector>
```

<span style="color: rgb(0, 0, 0);">Se tienen casos de adaptación para los casos de Kali Linux versión 2023 y 2024 donde se integran junto con la gestión de vulnerabilidades de Debian en base a la gestión de vulnerabilidades de sistemas no compatibles para el cual utilizamos la siguiente modificación al bloque de Debian de la siguiente manera.</span>

```xml
    <!-- Debian OS vulnerabilities -->
    <provider name="debian">
      <enabled>yes</enabled>
      <os>buster</os>
      <os>bullseye</os>
      <os>bookworm</os>
      <os allow="Kali GNU/Linux-2023,Kali GNU/Linux-2024">buster</os>
      <update_interval>1h</update_interval>
    </provider>
```

<span style="color: rgb(0, 0, 0);">Se utiliza el formato *OS\_name-OS\_majorcon* separados por comas y el atributo *allow* para incluir el sistema operativo. </span><span style="color: rgb(0, 0, 0);">Para aplicar los cambios reiniciamos Wazuh manager.</span>

```shell
sudo systemctl restart wazuh-manager
```

<span style="color: rgb(0, 0, 0);">En caso de revisión de la base de datos de Wazuh manager se deben seguir los siguientes pasos. En caso de no tener instalado SQLlite.  
</span>

```shell
sudo apt install sqlite3
```

<span style="color: rgb(0, 0, 0);">Seguidamente para abrir la base de datos de vulnerabilidades:</span>

```shell
sqlite3 /var/ossec/queue/vulnerabilities/cve.db
```

<span style="color: rgb(0, 0, 0);">Listamos las tablas en la base de datos.  
</span>

```sql
sqlite> .tables
```

<span style="color: rgb(0, 0, 0);">Para visualizar las tablas, Ej:  
</span>

```sql
sqlite> select * from <table>;
```

<span style="color: rgb(0, 0, 0);">El servidor de Wazuh crea automáticamente la base de datos de vulnerabilidad global con datos de los siguientes repositorios:</span>

- <span style="color: rgb(0, 0, 0);">https://canonical.com : se usa para extraer CVE para distribuciones Ubuntu Linux. </span>
- <span style="color: rgb(0, 0, 0);">https://www.redhat.com : se utiliza para extraer CVE para las distribuciones Red Hat y CentOS Linux. </span>
- <span style="color: rgb(0, 0, 0);">https://www.debian.org : se usa para extraer CVE para las distribuciones de Debian Linux. </span>
- <span style="color: rgb(0, 0, 0);">https://security.archlinux.org : se usa para extraer CVE para las distribuciones de Arch Linux. </span>
- <span style="color: rgb(0, 0, 0);">https://nvd.nist.gov : se usa para extraer CVE de la base de datos nacional de vulnerabilidad. </span>
- <span style="color: rgb(0, 0, 0);">https://feed.wazuh.com : se utiliza para obtener actualizaciones de seguridad de Microsoft (MSU) y fuentes ALAS. </span>

<span style="color: rgb(0, 0, 0);">Los feeds </span><span style="color: rgb(0, 0, 0);">contienen información de parches y CVE para productos de Microsoft y Amazon Linux. Utilizan el Catálogo de actualizaciones de Microsoft y el Centro de seguridad de Amazon Linux como fuentes de información. Wazuh analiza y formatea los datos antes de cargarlos en el feed de Wazuh.   
Una vez que el módulo de vulnerabilidades ha creado la base de datos de vulnerabilidad global que contiene los CVE, el proceso de detección busca paquetes vulnerables en las bases de datos de inventario.  
Un paquete se etiqueta como vulnerable cuando su versión coincide con las del rango afectado de un CVE. Las alertas muestran los resultados y el módulo almacena los hallazgos en un inventario de vulnerabilidades por agente. Este inventario contiene el estado actual de cada agente e incluye vulnerabilidades que han sido detectadas y no resueltas. Los usuarios pueden consultar el inventario para buscar alertas e información sobre vulnerabilidades.</span>

### <span style="color: rgb(53, 152, 219);">PDC 10: DETECCIÓN DE MALWARE INTEGRACIÓN CON YARA.  
</span>

Esta integración se utiliza con Wazuh para escanear archivos agregados o modificados en el terminal en busca de malware en el directorio /var/ossec/active-response/bin/. El módulo de respuesta activa YARA escanea archivos nuevos o modificados cada vez que el módulo FIM de Wazuh activa una alerta.

#### <span style="color: rgb(53, 152, 219);">Configuración.</span>

Configuraremos el terminal final e instalaremos Yara y sus dependencias configurando los módulos FIM y de respuesta activa. Para instalar YARA seguimos los siguientes pasos:

```shell
sudo apt update
sudo apt install -y make gcc autoconf libtool libssl-dev pkg-config jq
sudo curl -LO https://github.com/VirusTotal/yara/archive/v4.2.3.tar.gz
sudo tar -xvzf v4.2.3.tar.gz -C /usr/local/bin/ && rm -f v4.2.3.tar.gz
cd /usr/local/bin/yara-4.2.3/
sudo ./bootstrap.sh && sudo ./configure && sudo make && sudo make install && sudo make check
```

Verificamos la instalación

```shell
yara
```

\*El siguiente error aparece en distribuciones de Ubuntu.

```shell
/usr/local/bin/yara: error while loading shared libraries: libyara.so.9: cannot open shared object file: No such file or directory.
```

La solución del error se realiza desde un usuario con privilegios de root, solo con permisos sudo este comando es rechazado.

```shell
sudo echo "/usr/local/lib" >> /etc/ld.so.conf
ldconfig
```

Una vez solucionado el error o si este no se encuentra la respuesta del terminal deberia ser de la siguiente manera:

```shell
yara
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/vn3O79Kx6Gva8L4h-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/vn3O79Kx6Gva8L4h-image.png)

Proseguimos a descargar las reglas de detección de malware en Yara

```shell
sudo mkdir -p /tmp/yara/rules
sudo curl 'https://valhalla.nextron-systems.com/api/v1/get' \
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
-H 'Accept-Language: en-US,en;q=0.5' \
--compressed \
-H 'Referer: https://valhalla.nextron-systems.com/' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' \
--data 'demo=demo&apikey=1111111111111111111111111111111111111111111111111111111111111111&format=text' \
-o /tmp/yara/rules/yara_rules.yar
```

Se debe crear un archivo yara.sh

```bash
#!/bin/bash
# Wazuh - Yara active response
# Copyright (C) 2015-2022, Wazuh Inc.
#
# This program is free software; you can redistribute it
# and/or modify it under the terms of the GNU General Public
# License (version 2) as published by the FSF - Free Software
# Foundation.
         #------------------------- Gather parameters -------------------------#
# Extra arguments
read INPUT_JSON
YARA_PATH=$(echo $INPUT_JSON | jq -r .parameters.extra_args[1])
YARA_RULES=$(echo $INPUT_JSON | jq -r .parameters.extra_args[3])
FILENAME=$(echo $INPUT_JSON | jq -r .parameters.alert.syscheck.path)
# Set LOG_FILE path
LOG_FILE="logs/active-responses.log"
size=0
actual_size=$(stat -c %s ${FILENAME})
while [ ${size} -ne ${actual_size} ]; do
    sleep 1
    size=${actual_size}
    actual_size=$(stat -c %s ${FILENAME})
done
#----------------------- Analyze parameters -----------------------#
if [[ ! $YARA_PATH ]] || [[ ! $YARA_RULES ]]
then
    echo "wazuh-yara: ERROR - Yara active response error. Yara path and rules parameters are mandatory." >> ${LOG_FILE}
    exit 1
fi
#------------------------- Main workflow --------------------------#
# Execute Yara scan on the specified filename
yara_output="$("${YARA_PATH}"/yara -w -r "$YARA_RULES" "$FILENAME")"

if [[ $yara_output != "" ]]
then
    # Iterate every detected rule and append it to the LOG_FILE
    while read -r line; do
        echo "wazuh-yara: INFO - Scan result: $line" >> ${LOG_FILE}
    done <<< "$yara_output"
fi
exit 0;
```

```shell
nano /var/ossec/active-response/bin/yara.sh
```

Por último cambiamos el propietario del archivo para que root:wazuh lo pueda manejar:

```shell
sudo chown root:wazuh /var/ossec/active-response/bin/yara.sh
sudo chmod 750 /var/ossec/active-response/bin/yara.sh
```

Agregar que dentro del bloque `<syscheck>` del agente Wazuh en el archivo de configuración este configurado para monitorear el directorio /tmp/yara/malware:

```shell
nano /var/ossec/etc/ossec.conf
```

```xml
<directories realtime="yes">/tmp/yara/malware</directories>
```

Reiniciar el agente de Wazuh

```shell
sudo systemctl restart wazuh-agent
```

En el servidor de Wazuh tenemos que agregar eventos para extraer la información y los resultados de Yara.

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

```xml
<group name="syscheck,">
  <rule id="100300" level="7">
    <if_sid>550</if_sid>
    <field name="file">/tmp/yara/malware/</field>
    <description>File modified in /tmp/yara/malware/ directory.</description>
  </rule>
  <rule id="100301" level="7">
    <if_sid>554</if_sid>
    <field name="file">/tmp/yara/malware/</field>
    <description>File added to /tmp/yara/malware/ directory.</description>
  </rule>
</group>
```

La regla 100300 que especifica la modificación en un directorio es aplicable a un entorno delicado en el que los archivos deben mantener su integridad y la seguridad de estos sea de alta prioridad, en un despliegue con terminales remotos para usuario no es aconsejable ya que se consumen recursos al ejecutar el análisis con yara cada vez que un archivo cambia de tamaño al ser descargado o modificado dentro de un directorio monitorizado se recomienda utilizar el tipo de regla 100301 en caso de monitoreo a terminales de usuario.

```xml
<group name="yara,">
  <rule id="108000" level="0">
    <decoded_as>yara_decoder</decoded_as>
    <description>Yara grouping rule</description>
  </rule>
  <rule id="108001" level="12">
    <if_sid>108000</if_sid>
    <match>wazuh-yara: INFO - Scan result: </match>
    <description>File "$(yara_scanned_file)" is a positive match. Yara rule: $(yara_rule)</description>
  </rule>
</group>
```

En el archivo local\_decoder agregamos la siguiente información:

```shell
nano /var/ossec/etc/decoders/local_decoder.xml
```

```xml
<decoder name="yara_decoder">
  <prematch>wazuh-yara:</prematch>
</decoder>
<decoder name="yara_decoder1">
  <parent>yara_decoder</parent>
  <regex>wazuh-yara: (\S+) - Scan result: (\S+) (\S+)</regex>
  <order>log_type, yara_rule, yara_scanned_file</order>
</decoder>
```

#### <span style="color: rgb(53, 152, 219);">Emulación del ataque.  
</span>

Crear el archivo /tmp/yara/malware/malware\_downloader.sh en el punto final monitoreado para descargar muestras de malware.

```shell
touch /tmp/yara/malware/malware_downloader.sh
nano /tmp/yara/malware/malware_downloader.sh
```

```bash
#!/bin/bash
# Wazuh - Malware Downloader for test purposes
# Copyright (C) 2015-2022, Wazuh Inc.
# This program is free software; you can redistribute it
# and/or modify it under the terms of the GNU General Public
# License (version 2) as published by the FSF - Free Software
# Foundation.
function fetch_sample(){
  curl -s -XGET "$1" -o "$2"
}192.168.24.92
echo "WARNING: Downloading Malware samples, please use this script with  caution."
read -p "  Do you want to continue? (y/n)" -n 1 -r ANSWER
echo
if [[ $ANSWER =~ ^[Yy]$ ]]
then
    echo
    # Mirai
    echo "# Mirai: https://en.wikipedia.org/wiki/Mirai_(malware)"
    echo "Downloading malware sample..."
    fetch_sample "https://wazuh-demo.s3-us-west-1.amazonaws.com/mirai" "/tmp/yara/malware/mirai" && echo "Done!" || echo "Error while downloading."
    echo
    # Xbash
    echo "# Xbash: https://unit42.paloaltonetworks.com/unit42-xbash-combines-botnet-ransomware-coinmining-worm-targets-linux-windows/"
    echo "Downloading malware sample..."
    fetch_sample "https://wazuh-demo.s3-us-west-1.amazonaws.com/xbash" "/tmp/yara/malware/xbash" && echo "Done!" || echo "Error while downloading."
    echo
    # VPNFilter
    echo "# VPNFilter: https://news.sophos.com/en-us/2018/05/24/vpnfilter-botnet-a-sophoslabs-analysis/"
    echo "Downloading malware sample..."
    fetch_sample "https://wazuh-demo.s3-us-west-1.amazonaws.com/vpn_filter" "/tmp/yara/malware/vpn_filter" && echo "Done!" || echo "Error while downloading."
    echo
    # Webshell
    echo "# WebShell: https://github.com/SecWiki/WebShell-2/blob/master/Php/Worse%20Linux%20Shell.php"
    echo "Downloading malware sample..."
    fetch_sample "https://wazuh-demo.s3-us-west-1.amazonaws.com/webshell" "/tmp/yara/malware/webshell" && echo "Done!" || echo "Error while downloading."
    echo
fi
```

Ejecutamos el script malware\_downloader.sh para descargar muestras de malware al directorio /tmp/yara/malware.

```shell
sudo bash /tmp/yara/malware/malware_downloader.sh
```

#### <span style="color: rgb(53, 152, 219);">Resultado.</span>

Filtramos las alertas por rule.groups **yara**

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/weTluKdvhAMYC7Tq-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/weTluKdvhAMYC7Tq-image.png)

### <span style="color: rgb(53, 152, 219);">PDC 11: DETECCIÓN DE PROCESOS OCULTOS.  
</span>

Se realizara una prueba de concepto en Debian linux, descargando, compilando y cargando un rootkit. Luego, se configura el módulo rootcheck de Wazuh en el terminal para la detección de anomalías.

#### <span style="color: rgb(53, 152, 219);">Configuración.</span>

Para realizar el cometido primero realizamos los siguientes pasos desde el terminal:

```shell
sudo apt update
```

Instalamos los paquetes necesarios para el rootkit

```shell
sudo apt -y install gcc git
```

Configuramos el agente de Wazuh para ejecutar el escaneo de verificación de raíz cada 2 minutos.   
En el archivo ossec.conf

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

Seleccionamos *frequency* en 120 para realizar el análisis cada 2 minutos:

```xml
<frequency>120</frequency> 
```

Reiniciamos el agente de Wazuh para aplicar los cambios.

```shell
systemctl restart wazuh-agent
```

#### <span style="color: rgb(53, 152, 219);">Emulación del ataque.</span>

Obtenemos un código de rootkit desde Diamorphine de GitHub.

```shell
git clone https://github.com/m0nad/Diamorphine
```

Navegamos hasta el directorio Diamorphine y compilamos el código fuente.

```shell
cd /var/ossec/etc/Diamorphine/
make
```

- Se produce un error en la terminal cuando el comando make no realiza ninguna acción, verificamos la instalación de build-essential en caso de no estar instalado de la siguiente manera:`sudo apt-get install build-essential`
- Se produce un error en la terminal cuando linux/syscalls.h” no se encuentra en el sistema, para solucionar el problema se debe realizar la siguiente instalación.

```shell
sudo apt-get install linux-headers-$(uname -r)
```

Luego cargamos el módulo del kernel del rootkit.

```shell
insmod diamorphine.ko
```

Se debe ejecutar la señal kill 63 con el PID de un proceso aleatorio que se ejecuta en el terminal.   
Esto muestra el rootkit Diamorphine. De forma predeterminada, Diamorphine se oculta para que no la detectemos ejecutando el comando lsmod.

```shell
lsmod | grep diamorphine
kill -63 509
lsmod | grep diamorphine
```

Se deben ejecutar los siguientes comandos para ver cómo funciona el proceso rsyslogd es primero visible y luego ya no es visible. Este rootkit le permite ocultar procesos seleccionados del dominio ps. Enviando la señal de kill 31 oculta/muestra cualquier proceso.

```shell
ps auxw | grep rsyslogd | grep -v grep
```

Si el proceso no ocasiona ninguna salida es que algunos paquetes no están instalados, se deben seguir las siguientes instrucciones:

```shell
sudo apt-get install linux-headers-$(uname -r)
sudo apt-get install rsyslog
systemctl restart rsyslog
systemctl status rsyslog
```

Una vez instalados los paquetes tenemos:

```shell
ps auxw | grep rsyslogd | grep -v grep
```

salida:

```
root       22534  0.0  0.1 221772  6036 ?        Ssl  16:34   0:00 /usr/sbin/rsyslogd -n -iNONE
```

```shell
sudo kill -31 22534
```

```
ps auxw | grep rsyslogd | grep -v grep
```

El primer comando envía una señal kill al proceso 31 “rsyslogd”.  
El segundo comando muestra una lista de procesos que contienen la cadena “rsyslogd” en su nombre. La opción “-v grep” excluye cualquier proceso que contenga la cadena “grep” en su nombre.

#### <span style="color: rgb(53, 152, 219);">Resultados.</span>

Se pueden visualizar los datos de alerta en el panel de control de Wazuh.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/bWlk0MO7RTLDzGEg-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/bWlk0MO7RTLDzGEg-image.png)

Se realizo una detección de un posible rootkit.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/xDzK4g4hTEvFsIhc-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/xDzK4g4hTEvFsIhc-image.png)

Por seguridad se deben eliminar los archivos y la instalación del sistema de este rootkit para esto realizamos.

```shell
sudo rm -rf /var/ossec/etc/Diamorphine
```

### <span style="color: rgb(53, 152, 219);">PDC 12: SUPERVISIÓN DE LA EJECUCIÓN DE COMANDOS MALICIOSOS.  
</span>

Para este prueba configuramos ***Auditd*** en un terminal, con esto poder tener en cuenta todos los comandos ejecutados por un usuario determinado. Esto incluye comandos ejecutados por un usuario en modo o después de cambiar al usuario root. Configurar una regla de Wazuh personalizada para alertar de comandos sospechosos (sudo).

#### <span style="color: rgb(53, 152, 219);">Configuración.</span>

En el terminal final instalaremos Auditd posteriormente crearemos reglas para consultar todos los comandos ejecutados por un usuario con privilegios.

```shell
sudo apt -y install auditd
sudo systemctl start auditd
sudo systemctl enable auditd
```

Con credenciales root ejecutamos los comandos para agregar reglas de auditoría al archivo */etc/audit/audit.rules*

```shell
echo "-a exit,always -F auid=1000 -F egid!=994 -F auid!=-1 -F arch=b32 -S execve -k audit-wazuh-c" >> /etc/audit/audit.rules
echo "-a exit,always -F auid=1000 -F egid!=994 -F auid!=-1 -F arch=b64 -S execve -k audit-wazuh-c" >> /etc/audit/audit.rules
```

Cargamos las reglas para confirmar que están en el directorio correcto.

```shell
sudo auditctl -R /etc/audit/audit.rules
sudo auditctl -l
```

Debemos agregar la siguiente configuración al archivo del agente permitiendo que el agente lea el archivo de registros auditados en el directorio:

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

```xml
<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>
```

Para efectuar los cambios reiniciamos el agente de Wazuh.

```shell
sudo systemctl restart wazuh-agent
```

En el servidor debemos ejecutar los pasos siguientes para crear una lista CDB de programas malintencionados y reglas para detectar la ejecución de los programas de la lista. Revisamos los pares clave-valor en el archivo de búsqueda /var/ossec/etc/lists/audit-keys  
Esta lista CDB contiene claves y valores separados por dos puntos.

```
audit-wazuh-w:write
audit-wazuh-r:read
audit-wazuh-a:attribute
audit-wazuh-x:execute
audit-wazuh-c:command
```

Creamos una lista CDB y editamos el contenido /var/ossec/etc/lists/suspicious-programs

```
ncat:yellow
nc:red
tcpdump:orange
```

Agregamos la lista a la sección del archivo del servidor Wazuh en la sección **&lt;ruleset&gt;**

```shell
nano /var/ossec/etc/ossec.conf
```

```xml
<list>etc/lists/suspicious-programs</list>
```

Seguidamente creamos una regla de gravedad alta para activar cuando se ejecute un programa sospechoso. Para agregar esta nueva regla al archivo en el servidor Wazuh debemos añadir un grupo de reglas ubicado en el directorio de reglas.

```shell
sudo nano /var/ossec/etc/rules/local_rules.xml
```

```xml
<group name="audit">
  <rule id="100210" level="12">
      <if_sid>80792</if_sid>
  <list field="audit.command" lookup="match_key_value" check_value="red">etc/lists/suspicious-programs</list>
    <description>Audit: Highly Suspicious Command executed: $(audit.exe)</description>
      <group>audit_command,</group>
  </rule>
</group>
```

Para aplicar los cambios realizados reiniciamos el administrador de Wazuh.

```shell
sudo systemctl restart wazuh-manager
```

#### <span style="color: rgb(53, 152, 219);">Emulación del ataque.</span>

En el terminal de prueba utilizaremos un programa catalogado como “peligroso” intencionalmente con **netcat**.

```shell
sudo apt -y install netcat
nc -v
```

#### <span style="color: rgb(53, 152, 219);">Resultados.</span>

Con estos comandos instalamos Netcat es una herramienta de red que se utiliza para leer y escribir datos a través de conexiones de red utilizando TCP o UDP.

El segundo comando inicia sesión en modo verbose mostrando la información de forma mas detallada sobre cada paso al realizar la conexión.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/O4GgGPyk7XR4022x-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/O4GgGPyk7XR4022x-image.png)

### <span style="color: rgb(53, 152, 219);">PDC 13: DETECCIÓN DE UN ATAQUE DE SHELLSHOCK.  
</span>

Wazuh es capaz de detectar un ataque Shellshock mediante el análisis de los registros del servidor web recopilados de un punto final monitoreado. En este caso de uso, configura un servidor web Apache en el punto final de víctima y simula un ataque de shellshock.

En este caso se necesitan de 2 terminales el primero el servidor web que sufrirá el ataque de un terminal atacante con sistema operativo Debian emulando el envío de solicitudes HTTP maliciosas al servidor web Apache.

#### <span style="color: rgb(53, 152, 219);">Configuración.</span>

En el terminal víctima se necesitan los paquetes actualizados del servidor Apache:

```shell
sudo apt update
sudo apt install apache2
```

Si el firewall está activo debe modificarse para permitir el acceso externo a los puertos web.

```shell
sudo ufw app list
sudo ufw allow 'Apache'
sudo ufw status
```

Comprobamos que el servidor está siendo ejecutado:

```shell
sudo systemctl status apache2
```

Agregamos las siguientes líneas al archivo de configuración del agente. Esto configura el agente Wazuh para monitorear los registros de acceso de su servidor Apache en el archivo de configuración.

```shell
nano /var/ossec/etc/ossec.conf
```

```xml
<localfile>
    <log_format>syslog</log_format>
    <location>/var/log/apache2/access.log</location>
</localfile>
```

Para aplicar los cambios reiniciamos el agente de Wazuh.

```shell
sudo systemctl restart wazuh-agent
```

#### <span style="color: rgb(53, 152, 219);">Emulación del ataque.</span>

La dirección IP del terminal (192.168.24.73) nos sirve para ejecutar el siguiente comando desde el terminal Debian del atacante.

```shell
sudo curl -H "User-Agent: () { :; }; /bin/cat /etc/passwd" 192.168.24.73
```

El comando realiza un ataque de Shellshock es una vulnerabilidad de seguridad en el intérprete de línea de comandos Bash que se utiliza en muchos sistemas operativos Linux y Liberation Serif Unix. La vulnerabilidad permite a un atacante ejecutar código arbitrario en un sistema vulnerable enviando un comando especial al intérprete Bash.  
El comando en particular que proporcionaste intenta ejecutar el comando /bin/cat /etc/passwd en el sistema vulnerable. El comando /bin/cat /etc/passwd muestra el archivo /etc/passwd, que contiene información sobre todos los usuarios del sistema.  
Si el sistema vulnerable está infectado con Shellshock, el comando se ejecutará y el atacante podrá ver la información de todos los usuarios del sistema

#### <span style="color: rgb(53, 152, 219);">Resultados.</span>

Se detecta un ataque de shellshock con nivel de gravedad debido a que se realizaron algunos intentos.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/NqdAeOQB54s18KRf-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/NqdAeOQB54s18KRf-image.png)

# Envío de alertas por correo Wazuh manager

Para configurar Wazuh para enviar alertas por correo electrónico, los ajustes de correo electrónico deben configurarse en la sección del archivo principal de configuración ossec.conf.

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

```xml
<ossec_config>
    <global>
        <email_notification>yes</email_notification>
        <email_to>me@test.com</email_to>
        <smtp_server>mail.test.com</smtp_server>
        <email_from>wazuh@test.com</email_from>
    </global>
</ossec_config>
```

Una vez configurado el apartado anterior, se debe establecer en el nivel de alerta mínimo que activará un correo electrónico. De forma predeterminada, este nivel se establece en 12.email\_alert\_level.

```xml
<ossec_config>
  <alerts>
      <email_alert_level>12</email_alert_level>
  </alerts>
</ossec_config>
```

Para aplicar los cambios se debe reiniciar el servidor de Wazuh:

```shell
systemctl restart wazuh-manager
```

Para que los cambios surtan efecto se debe realizar la **configuración SMTP.** Las alertas de correo electrónico de Wazuh no admiten servidores SMTP con autenticación como Gmail. Sin embargo, puede usar una retransmisión de servidor, como Postfix, para enviar estos correos electrónicos. Para configurar Postfix con Gmail seguimos los pasos a continuación:

El tipo de configuración del servidor de correo se establece en: *sin configuración*.

```shell
sudo apt-get update && apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules
```

Para configurar Postfix se debe crear el archivo main de configuración.

```shell
sudo nano /etc/postfix/main.cf
```

```
relayhost = [smtp-mail.outlook.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_use_tls = yes
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
```

Establezca la dirección de correo electrónico y la contraseña del remitente reemplazando *USERNAME* y *PASSWORD* con datos reales.  
Para este paso se tiene que crear una contraseña de aplicación para que no se solicite la autenticación en 2 pasos y se pueda utilizar para las notificaciones.

```shell
echo [smtp-mail.outlook.com]:587 correo@outlook.com:******** > /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
chmod 400 /etc/postfix/sasl_passwd
```

Cambiamos los permisos de base de datos de contraseña para que solo usuario root pueda verla.

```shell
chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
```

Se debe reiniciar Postfix para aplicar los cambios:

```shell
systemctl restart postfix
```

Prueba de configuración:  
Reemplazando los datos de dirección de correo electrónico. Verificamos que se reciba este correo electrónico de prueba.you@example.com:

```shell
echo "Prueba de correo electrónico" | mail -s "Prueba n°1" -r "correo_que_envia@outlook.com"  correo_que_recibe@outlook.com
```

En la bandeja de entrada tenemos:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/J6DHBW58GCvnKVO6-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/J6DHBW58GCvnKVO6-image.png)

Con la prueba realizada se configuran las notificaciones por correo electrónico en el archivo de configuración de Wazuh.

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

```xml
<global>
  <email_notification>yes</email_notification>
  <smtp_server>localhost</smtp_server>
  <email_from>USERNAME@gmail.com</email_from>
  <email_to>you@example.com</email_to>
</global>
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/LrJzEiTI2xmDh5Kc-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/LrJzEiTI2xmDh5Kc-image.png)

Para este ejemplo modificamos el nivel de alerta de correo a nivel 7 para ver distintos tipos de alertas enviados al correo electrónico, sin embargo en un entorno de producción es recomendable que sean alertas de nivel máximo.

Reiniciamos el servidor para aplicar los cambios:

```shell
systemctl restart wazuh-manager
```

El correo de prueba es un e-mail temporal al cual nos llega la prueba de eventos, se puede configurar el mismo destinatario y origen con el mismo correo pero para probar la funcionalidad de reenvío se realizó la prueba con 2 correos diferentes.

Alerta en el correo de prueba [***noxatrubaudi-8034@yopmail.com***](mailto:noxatrubaudi-8034@yopmail.com).

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/aiP5oiOThmNJe02O-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/aiP5oiOThmNJe02O-image.png)

# Monitoreo de actividad con usuarios en agentes

El primer objetivo a cumplir es el de realizar un registro de logs en el sistema para los agentes monitoreados. Para esto utilizando la maquina virtual de prueba nos dirigimos al archivo de configuración.

```shell
nano /etc/rsyslog.conf
```

Agregamos al archivo:

```shell
auth,authpriv.* /var/log/auth.log
systemctl restart rsyslog.service
```

Es recomendable quitar el comentario a la linea LogLevel para una información mas precisa.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/DraXZqGVkCfilCMA-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/DraXZqGVkCfilCMA-image.png)

El archivo “**/var/log/auth.log**” tendrá los registros con lo que probaremos los distintos tipos de eventos que pueden darse.

Ejemplo "useradd"  
Recuperamos la salida en auth.log y así tendremos ejemplos de logs para poder ser analizados por wazuh manager:  
Para agregar usuario

```
Sep  5 11:27:26 xubuntu-VM useradd[205364]: new user: name=ejemplo, UID=1001, GID=1001, home=/home/ejemplo, shell=/bin/sh, from=/dev/pts/1
```

Introducimos el log generado en nuestro terminal en la herramienta **Ruleset** **test** de Wazuh manager para comprobar si es que existen reglas asociadas a este tipo de eventos.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/98S6UjSchIE2KNZP-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/98S6UjSchIE2KNZP-image.png)

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/sDOgJSRBVxboQTtA-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/sDOgJSRBVxboQTtA-image.png)

En este caso observamos que tienen reglas asociadas a este tipo de eventos y la extracción de este tipo de datos que se pueden observar como el nombre de la acción **useradd** y datos como el nombre del usuario creado así como los identificadores de usuario o grupo y la interfaz de línea de comandos que en este caso es /bin/sh.

Para probar los logs registramos 3 eventos con un nombre cualquiera.

```shell
useradd cuatro
usermod -aG cuatro
userdel cuatro
```

Revisamos los logs del archivo en /var/log/auth.log

```
Sep  6 09:55:29 xubuntu-VM useradd[220043]: new user: name=cuatro, UID=1001, GID=1001, home=/home/cuatro, shell=/bin/sh, from=/dev/pts/3
Sep  6 09:55:56 xubuntu-VM usermod[220054]: add 'cuatro' to shadow group 'sudo'
Sep  6 09:56:00 xubuntu-VM userdel[220061]: delete user 'cuatro'
```

Para lo cual se generan las alertas de usuario agregado y usuario eliminado por defecto en wazuh   
manager.

En el caso del comando useradd tenemos:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/LTb6tsu6uZL7Y1AA-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/LTb6tsu6uZL7Y1AA-image.png)

En el caso del comando userdel tenemos:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/nmzpdfDlMaNYE0FE-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/nmzpdfDlMaNYE0FE-image.png)

Debido a que no se tiene una alerta para el evento de asignación de privilegios al usuario tenemos que crear la regla personalizada analizando el log generado en **/var/log/auth.log** y crear el decodificador para dicho evento específico.

```
Log: Sep  5 19:47:44 ubuntu usermod[19978]: add 'prueba' to shadow group 'sudo'
```

El decodificador queda de la siguiente manera:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/1fMw8lbp95iLkhdO-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/1fMw8lbp95iLkhdO-image.png)

Realizamos la prueba en Decoders Test para verificar que se reconocen los parámetros.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/HzR8klRP7z4ZLMIV-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/HzR8klRP7z4ZLMIV-image.png)

Observamos que se pueden extraer los datos de nombre de usuario y grupo al que fue asignado por lo cual se realizara la regla personalizada para este evento.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/GZEkH7XUMaMb7NX6-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/GZEkH7XUMaMb7NX6-image.png)

Una vez realizada esta regla probamos el log con **Ruleset Test** de Wazuh para ver si se genera de manera correcta.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/A2jtsM9kufYBxtLa-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/A2jtsM9kufYBxtLa-image.png)

Realizadas las pruebas utilizaremos la maquina virtual para proceder con la generación de alertas de niveles 8 y 10 respectivamente:  
Usuario creado:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/0k7NJqT2D2HExMhv-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/0k7NJqT2D2HExMhv-image.png)

Escala de privilegios:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/vWxSK0c5rhcb69Cz-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/vWxSK0c5rhcb69Cz-image.png)

Eliminación de usuario:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/tQYGL3s2ToesUBZi-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/tQYGL3s2ToesUBZi-image.png)

En el agente de Wazuh agregamos este bloque en el archivo de configuración para monitorizar el archivo sudoers.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/btZxw9IpigQcT0cc-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/btZxw9IpigQcT0cc-image.png)

Esto realizará un monitoreo en tiempo real del archivo para enviar una alerta de modificaciones.  
Con distintos escenarios podemos incrementar la cantidad de reglas a partir de diferentes eventos como mostraremos a continuación:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/iwhcu6nnSTYdZOfL-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/iwhcu6nnSTYdZOfL-image.png)

Las reglas se modificaron de la siguiente manera:

- 100060 Se realizo la regla para activarse en caso de que un usuario se añada ya sea al grupo sudo o al grupo admin que poseen privilegios de ejecución.
- 100061 Esta regla actúa de manera similar a la anterior sin embargo es de menor nivel por que indica que un usuario nuevo se añade a un grupo existente no necesariamente con privilegios.
- 100062 Se creó en base a la regla generada de integridad de archivos. Si se ejecuta un cambio en los directorios monitoreados en tiempo real y además es coincidente con “/etc/sudoers” esta alerta se activara con nivel crítico.
- 100063 Se creó en base a la regla 5903 cuando se elimina un usuario. Si se detecta la eliminación y además es coincidente con “root” se genera una alerta de nivel crítico.

# Envío de alertas mediante bot de Telegram

<span style="color: rgb(0, 0, 0);">En esta publicación, crearemos un bot de Telegram para recibir alertas de Wazuh directamente en un chat de Telegram usando el módulo de integraciones en Wazuh. </span>

<span style="color: rgb(0, 0, 0);">Como primer paso crearemos un bot de Telegram con la ayuda de BotFather.</span>

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/B8QdRKhzciYtkQNF-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/B8QdRKhzciYtkQNF-image.png)

<span style="color: rgb(0, 0, 0);">Para crear el bot seguimos los siguientes comandos:  
Crear bot:  
`/newbot`</span>

<span style="color: rgb(0, 0, 0);">Nos pedira darle un nombre al bot:  
`wazuhbot2050_bot`  
</span>

<span style="color: rgb(0, 0, 0);">Nos dara un número nuevo de API para el bot, la respuesta que en este caso es:  
`<strong>ClaveAPI2050Alfanumerica </strong>`  
</span>

<span style="color: rgb(0, 0, 0);">La clave API es muy importante por que se incluirá a los scripts de Wazuh manager y se utiliza para obtener el chat ID.  
</span>

<span style="color: rgb(0, 0, 0);">Utilizaremos un script en Wazuh manager de la siguiente manera:</span>

```shell
sudo nano /var/ossec/integrations/custom-telegram
```

```bash
#!/bin/sh
WPYTHON_BIN="framework/python/bin/python3"
SCRIPT_PATH_NAME="$0"
DIR_NAME="$(cd $(dirname ${SCRIPT_PATH_NAME}); pwd -P)"
SCRIPT_NAME="$(basename ${SCRIPT_PATH_NAME})"
case ${DIR_NAME} in
    */active-response/bin | */wodles*)
        if [ -z "${WAZUH_PATH}" ]; then
            WAZUH_PATH="$(cd ${DIR_NAME}/../..; pwd)"
        fi
        PYTHON_SCRIPT="${DIR_NAME}/${SCRIPT_NAME}.py"
    ;;
    */bin)
        if [ -z "${WAZUH_PATH}" ]; then
            WAZUH_PATH="$(cd ${DIR_NAME}/..; pwd)"
        fi
        PYTHON_SCRIPT="${WAZUH_PATH}/framework/scripts/${SCRIPT_NAME}.py"
    ;;
     */integrations)
        if [ -z "${WAZUH_PATH}" ]; then
            WAZUH_PATH="$(cd ${DIR_NAME}/..; pwd)"
        fi
        PYTHON_SCRIPT="${DIR_NAME}/${SCRIPT_NAME}.py"
    ;;
esac
${WAZUH_PATH}/${WPYTHON_BIN} ${PYTHON_SCRIPT} "$@"
```

<span style="color: rgb(0, 0, 0);">Si deseamos que el registro de alertas se envíe a un grupo en específico debemos ingresar a telegram web desde el navegador y copiar el ID de grupo al script de python incluyendo el signo “-”.</span>

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/gvCn2eKVn429KQSv-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/gvCn2eKVn429KQSv-image.png)

Accediendo desde Telegram web se puede observar el numero ID de grupo que se genera, dato que necesitaremos posteriormente para reenviar las alertas al grupo ya que es mas conveniente en caso de tener un incidente de gran escala que varias personas se enteren, En el inicialmente se encuentra el bot y el numero de la persona que realiza la integración.

Configuramos el script de telegram con el dato extra del grupo para realizar la función del script.

```python
#!/usr/bin/env python
import sys
import json
import requests
from requests.auth import HTTPBasicAuth
#CHAT_ID="xxxx"
CHAT_ID="-NumeroID"
# Read configuration parameters
alert_file = open(sys.argv[1])
hook_url = sys.argv[3]

# Read the alert file
alert_json = json.loads(alert_file.read())
alert_file.close()
# Extract data fields
alert_level = alert_json['rule']['level'] if 'level' in alert_json['rule'] else "N/A"
description = alert_json['rule']['description'] if 'description' in alert_json['rule'] else "N/A"
agent = alert_json['agent']['name'] if 'name' in alert_json['agent'] else "N/A"
username = alert_json['data']['dstuser'] if 'dstuser' in alert_json['data'] else "N/A"
source = alert_json['data']['scrip'] if 'scrip' in alert_json['data'] else "N/A"
# Generate request
msg_data = {}
msg_data['chat_id'] = CHAT_ID
msg_data['text'] = {}
msg_data['text']['description'] =  description
msg_data['text']['alert_level'] = str(alert_level)
msg_data['text']['agent'] =  agent
msg_data['text']['username'] =  username
msg_data['text']['source'] =  source
headers = {'content-type': 'application/json', 'Accept-Charset': 'UTF-8'}
# Send the request
requests.post(hook_url, headers=headers, data=json.dumps(msg_data))
sys.exit(0)
```

```shell
nano /var/ossec/integrations/custom-telegram.py
```

En los scripts iniciales el grupo que administraba las operaciones de las integraciones con wazuh era “ossec” sin embargo desde la version 4.4.5 el grupo que administra estos eventos es “wazuh”

```shell
chown root:wazuh /var/ossec/integrations/custom-telegram*
chmod 750 /var/ossec/integrations/custom-telegram*
```

Es importante mencionar que en este caso se trata de una integración externa personalizada ya que Telegram no se encuentra entre las pruebas de concepto y el nombre de referenciación debe comenzar con “custom-”.   
Las configuraciones se realizan en el archivo ossec.conf. Se pueden utilizar los siguientes parámetros:

- `<strong>name</strong>:` Nombre del script que realiza la integración. En el caso de una integración personalizada como la que se analiza en este artículo, el nombre debe comenzar con "personalizado-".
- `<strong>hook_url</strong>:` URL proporcionada por la API del software para conectarse a la propia API. Su uso es opcional, ya que se puede incluir en el script.
- `<strong>api_key</strong> :` Clave de la API que nos permite utilizarla. Su uso también es opcional por la misma razón que el uso de hook\_url es opcional.
- `<strong>level</strong> :` establece un filtro de nivel para que el script no reciba alertas por debajo de cierto nivel.
- `<strong>rule_id</strong> :` establece un filtro para los identificadores de alerta.
- `<strong>group</strong> : `Establece un filtro de grupo de alertas.
- `<strong>event_location</strong> :` establece un filtro de fuente de alerta.
- `<strong>alert_format</strong> :` Indica que el script recibe las alertas en formato JSON (recomendado). De forma predeterminada, el script recibirá las alertas en formato full\_log.

La configuración que realizaremos en Wazuh manager se da de la siguiente manera:

```shell
nano /var/ossec/etc/ossec.conf
```

```xml
    <integration>  
        <name>custom-telegram</nasystemctl restart wazuh-managerme>
        <level>7</level> <hook_url>https://api.telegram.org/botClaveAPI2050Alfanumerica/sendMessage</hook_url>
        <alert_format>json</alert_format>
    </integration> 
```

Para que los cambios se apliquen realizamos un restart.

```shell
systemctl restart wazuh-manager
```

Es recomendable asignar el rol de administrador al bot creado, ya que sin realizar esta acción no podrá enviar mensajes, pues está restringido por defecto.

Una vez realizadas las configuraciones, el grupo creado en Telegram con el bot será el que reciba las alertas y podrá ser visualizado desde un rango establecido por el nivel en las vulnerabilidades como se muestra a continuación.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/pEIV7uNsmUJIBzGD-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/pEIV7uNsmUJIBzGD-image.png)

<div class="notranslate" id="bkmrk--4" style="all: initial;"></div>

# Análisis de logs en Bases de datos

#### <span style="color: rgb(53, 152, 219);">Mariadb para análisis de logs.</span>

Actualización de los repositorios del sistema.

```shell
sudo apt-get update
```

Actualización e instalación de MariaDB

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

Una vez instalada Mariadb comprobamos con el estatus:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/rifyBkWXH9PaF7I7-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/rifyBkWXH9PaF7I7-image.png)

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
mysql -u root -p
```

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

```mysql
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.

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

Ingresamos de forma exitosa:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/xyl4WWLjQiBeh4Iu-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/xyl4WWLjQiBeh4Iu-image.png)

Habilitamos el acceso remoto de Mariadb, salimos del usuario creado e ingresamos al archivo de configuración desde el terminal y cambiamos el valor de bind address.

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

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/QdrLECXhZjyT0Y3u-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/QdrLECXhZjyT0Y3u-image.png)

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.

```shell
sudo systemctl restart mariadb
```

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

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

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/Ikm3NHTyrWQKzSFO-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/Ikm3NHTyrWQKzSFO-image.png)

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

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

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/TEITioQzYvPOWZcA-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/TEITioQzYvPOWZcA-image.png)

Los logs se registran en el directorio /var/lib/mysql/server\_audit.log. Luego debemos instalar el plugging de auditoria en el servidor mariadb.

```shell
mysql -u remoto -p
```

```mysql
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.

```shell
sudo apt-get install -y rsyslog
```

Después debemos enviar los registros al servidor de Wazuh. En 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.

```shell
sudo nano /etc/rsyslog.conf
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/WwHR5qc8tGUoMFlK-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/WwHR5qc8tGUoMFlK-image.png)

Para aplicar los cambios se debe reiniciar el servicio Rsyslog.

```shell
systemctl restart rsyslog
```

Se debe habilitar el complemento de auditoria

```shell
nano /etc/mysql/my.cnf
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/1oVZe5F6LZ5zSFQk-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/1oVZe5F6LZ5zSFQk-image.png)

Reiniciamos para aplicar los cambios

```shell
systemctl restart mariadb
```

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

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

Verificamos el archivo de auditoria.

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

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/H7PEHzqX3HxDSH0q-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/H7PEHzqX3HxDSH0q-image.png)

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

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/xMLx9Yk6R0I9OH5f-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/xMLx9Yk6R0I9OH5f-image.png)

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.

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

```xml
<!-- Conexion por puerto 514 a mariadb -->
  <remote>
    <connection>syslog</connection>
    <port>514</port>
    <protocol>udp</protocol>
    <allowed-ips>192.168.24.0/24</allowed-ips>
  </remote>
```

```shell
systemctl restart wazuh-manager.service
```

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

```xml
<!--  Registro de logs mariadb -->  
<localfile>
    <log_format>syslog</log_format>
    <location>/var/log/mysql/mariadb-audit.log</location>
  </localfile>
```

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

```xml
<!-- 
                                            REGLAS PERSONALIZADAS MARIADB 
-->
<group name="mariadb-syslog,">
                                            <!-- Acceso fallido  -->

	<rule id="100002" level="4">
	  <if_sid>88100</if_sid>
	  <match>FAILED_CONNECT</match>
	  <description>Acceso fallido a base de datos mariadb.</description>
	</rule>
</group>
```

```shell
systemctl restart wazuh-manager
```

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

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/oRbLNfeBXaAriGY9-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/oRbLNfeBXaAriGY9-image.png)

#### <span style="color: rgb(53, 152, 219);">Elaboración de reglas en Wazuh manager para la auditoria de bases de datos.</span>

<span style="color: rgb(0, 0, 0);">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.  
</span>

```shell
nano /var/ossec/etc/ossec.conf
```

Dentro del archivo de configuración en &lt;ossec\_config&gt; y &lt;ruleset&gt;

```xml
  <ruleset>
<!-- Código anterior ... -->

<!-- Directorio de reglas locales de wazuh -->
    <rule_dir>/var/ossec/etc/rules/local_rules.xml</rule_dir>
  </ruleset>
```

#### <span style="color: rgb(53, 152, 219); background-color: rgb(255, 255, 255);">Decodificador para MariaDB</span>

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, en el archivo de decodificadores locales de Wazuh:

```xml
<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.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/bC0xQ0LeV4S0tp3k-image.png) ](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/bC0xQ0LeV4S0tp3k-image.png)[ ![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/NXyOuo2DzSTsQQPb-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/NXyOuo2DzSTsQQPb-image.png)

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.

#### <span style="color: rgb(53, 152, 219);">Reglas personalizadas para MariaDB.</span>  


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

```xml
<!-- 
                                            REGLAS PERSONALIZADAS MARIADB 
-->
<group name="mariadb-syslog,">
                                            <!-- Acceso fallido  -->
	<rule id="100002" level="4">
	  <if_sid>88100</if_sid>
	  <match>FAILED_CONNECT</match>
	  <description>Acceso fallido a base de datos mariadb.</description>
	</rule>
                                <!-- Eliminación de tabla, base de datos, usuario  -->
    <rule id="100003" level="4">
        <if_sid>88100</if_sid>
        <match>DROP TABLE</match>
        <description>Tabla eliminada en Mariadb.</description>
    </rule>	
	<rule id="100004" level="6">
        <if_sid>88100</if_sid>
        <match>DROP DATABASE</match>
        <description>Base de datos eliminada en Mariadb</description>
	</rule>
	<rule id="100005" level="8">
        <if_sid>88100</if_sid>
        <match>DROP USER</match>
        <description>Alerta inusual usuario eliminado en Mariadb</description>
	</rule>
                                <!-- Creación de usuario o cambio de atributos  -->
	<rule id="100006" level="3">
        <if_sid>88100</if_sid>
        <match>CREATE USER</match>
        <description>Usuario creado en Mariadb</description>
	</rule>
	<rule id="100007" level="8">
        <if_sid>88100</if_sid>
        <match>GRANT ALL PRIVILEGES</match>
        <description>Alerta inusual se han cambiado los atributos de un usuario en Mariadb</description>
	</rule>	
</group>
```

Para realizar la prueba ingresamos de forma remota

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

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

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/x1cejEkW0VfI3OPa-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/x1cejEkW0VfI3OPa-image.png)[ ![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/dI7gAz2WYTFRy6qZ-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/dI7gAz2WYTFRy6qZ-image.png)

Posteriormente observamos la alerta en Wazuh manager.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/NDsLpixofTKAC3hM-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/NDsLpixofTKAC3hM-image.png)

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

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/za3uOhO2nO3SbT6q-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/za3uOhO2nO3SbT6q-image.png)

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.

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/yoWCJPCtzQ1V4GaK-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/yoWCJPCtzQ1V4GaK-image.png)

<div class="notranslate" id="bkmrk--18" style="all: initial;"></div>

# Integración con antivirus ClamAV

Wazuh detecta archivos maliciosos mediante la integración con ClamAV , el cual es un motor antimalware gratuito y de código abierto para detectar varios tipos de malware, incluidos virus y troyanos.

ClamAV es un conjunto de herramientas antimalware de código abierto diseñado para diversos casos de uso, como seguridad de terminales, escaneo web y tiene las siguientes características:

- Ofrece protección en tiempo real para puntos finales de Linux.
- Proporciona actualizaciones automáticas a la base de datos de malware.
- Admite todos los formatos de archivos de correo estándar de forma predeterminada.
- Admite varios formatos de archivo como ZIP y RAR.
- Admite archivos de documentos comunes, como archivos de MS Office y Mac Office, HTML, RTF y PDF.
- Está diseñado con un actualizador de bases de datos avanzado que puede aprovechar actualizaciones programadas o firmas digitales.
- Utiliza un escáner de línea de comandos.
- Tiene soporte integrado para ejecutables ELF y archivos ejecutables portátiles empaquetados con UPX, FSG, Petite, NsPack, wwpack32, MEW, Upack y ofuscados con SUE y otros.

#### <span style="color: rgb(35, 111, 161);">Configuración.</span>

Puede configurar ClamAV y recopilar sus registros desde puntos finales de Linux y Windows. Para recopilar registros de ClamAV de puntos finales de Linux, elimine la etiqueta de comentario **\#** antes de la declaración "*LogSyslog true*" en el archivo de configuración. Quitar el comentario a esta declaración reenvía los registros de ClamAV al archivo Syslog /var/log/syslog.

Para instalar el entorno de prueba tendremos que ejecutar los siguientes comandos.

```shell
sudo apt-get update
sudo apt-get install clamav-daemon
sudo chmod 644 /etc/clamav/clamd.conf
sudo chmod 644 /etc/clamav/freshclam.conf
sudo chown clamav:adm /etc/clamav/clamd.conf
sudo chown clamav:adm /etc/clamav/freshclam.conf
```

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/1dwAmWzDoA5evBNq-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/1dwAmWzDoA5evBNq-image.png)

##### <span style="color: rgb(0, 0, 0);">Instalación de Rsyslog.</span>  


```shell
sudo apt-get install rsyslog -y
```

##### Configuración daemon de Clamav.

Modificar los datos en el archivo de configuración.

```shell
sudo nano /etc/clamav/clamd.conf
```

```
LogSyslog true
#LogFile /var/log/clamav/clamav.log
```

```shell
sudo nano /etc/clamav/freshclam.conf
```

```
LogVerbose true
LogSyslog true
```

Modificar los siguientes apartados en clamd.conf que es el scanner mediante linea de comandos.

```shell
sudo nano /usr/local/etc/clamd.conf
```

```
# Comment or remove the line below.
# Example
```

```shell
sudo nano /usr/local/etc/freshclam.conf
```

```
# Comment or remove the line below.
# Example
UpdateLogFile /var/log/clamav/freshclam.log
```

```shell
systemctl restart clamav-daemon 
systemctl enable clamav-daemon 
systemctl restart wazuh-agent
```

```shell
sudo usermod -aG clamav $USER
sudo usermod -aG adm $USER
sudo chmod 666 /var/run/clamav/clamd.ctl
```

**Comando de prueba para análisis y almacenamiento en syslog:**

```shell
clamscan --stdout --no-summary -i -r /directorio/de/escaneo | logger -t "clamd[5286]"
```

**Comando de prueba para respuesta en consola de archivos infectados:**

```shell
clamscan --stdout --no-summary -i -r /home/rchavez/Descargas/Malware
```

##### **Agente de Wazuh.**

Si no se lee por defecto se debe añadir el apartado **localfile** que obliga a realizar el registro del directorio **syslog** para que Wazuh agent lo analice cada vez que se realice un escaneo de cualquier directorio.

```shell
nano /var/ossec/etc/ossec.conf
```

```xml
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/syslog</location>
  </localfile>
```

```shell
systemctl restart wazuh-agent
```

Una vez realizados los ajustes podemos observar diferentes tipos de alertas generadas.

Cuando se detiene el servicio de clamAV tenemos:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/ubBDcdiil3ktRcIX-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/ubBDcdiil3ktRcIX-image.png)

Cuando se detecta un archivo infectado tenemos:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/35Nq7XnYwYrnZKcY-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/35Nq7XnYwYrnZKcY-image.png)

Cuando se tiene un error inesperado o mala configuración tenemos:

[![image.png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/scaled-1680-/DJdKaWuisoTiHdTh-image.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2024-04/DJdKaWuisoTiHdTh-image.png)

##### **Actualización automática de freshclam.**

Configuración de cantidad de veces al día que se actualiza clamav-freshclam de forma automática modificando el archivo de configuración. Por defecto se establece en 24 pero dependiendo de la cantidad de recursos del equipo esta puede modificarse.

```shell
sudo nano /etc/clamav/freshclam.conf
```

```
#Para una actualización de 6 veces al dia.
Checks 6
```

```shell
sudo systemctl restart clamav-freshclam
```

##### **Actualización manual de freshclam.**

Configuración manual para actualizar clamav-freshclam realizando los siguientes siguientes comandos:

```shell
sudo systemctl stop clamav-freshclam.service
sudo freshclam
sudo systemctl restart clamav-freshclam.service
```

##### **Programación regular análisis con clamscan.**

Para realizar un análisis periódico y que los archivos analizados por clamscan y visualizados en wazuh se puede programar un crontab en terminales linux de la siguiente manera.

Accedemos como usuario con privilegios debido a que la detención de programas y posterior "*restart*" utilizan permisos root.

```shell
sudo su
crontab -e
```

Dentro de crontab utilizamos horarios en los que los equipos no tengan una utilización demandante.

```
10 12 * * * sudo systemctl stop clamav-freshclam.service
11 12 * * * sudo freshclam
15 12 * * * sudo systemctl restart clamav-freshclam.service
20 12 * * * /usr/local/bin/clamscan --stdout --no-summary -i -r /home/rchavez/Descargas/Malware 2>&1 | logger -t "clamd[5286]
```

Utilizamos la ruta completa de *clamscan* para que sea interpretado de manera correcta, obteniendo alerta de actualización con *freshclam* así como también de malware en caso de encontrarse una coincidencia positiva.

# Integración complementaria de reglas YARA

Para realizar la integración del agente de Wazuh con Yara en los host terminales monitorizados se utilizarán las reglas de Wazuh manager de la prueba de concepto junto con un repositorio de Github de yara para realizar la integración complementaria.

Para la instalación de un agente de Wazuh integrado con Yara se propone un script que automatiza el proceso de instalación e integración de estas 2 herramientas en un terminal Linux.

```bash
#!/bin/bash
# 1. Revisión de la actualización de repositorios
# 2. El proceso se mostrara paso a paso para identificacion de posibles fallas
set -x
sudo apt install curl
sudo apt install git

# 2. Instalacion de claves GPG Wazuh
sudo curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
sleep 3

# 3. Añadiendo el repositorio de Wazuh
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list
read -p 'Introduzca el nombre del agente (minúsculas en formato nombre.apellido): ' nombre

# 4. Descarga e inicialización del agente wazuh.deb
curl -so wazuh-agent_4.7.3-1_amd64.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.7.3-1_amd64.deb && sudo WAZUH_MANAGER="172.28.1.69" WAZUH_AGENT_GROUP="UGTD" WAZUH_AGENT_NAME="$nombre" dpkg -i ./wazuh-agent_4.7.3-1_amd64.deb
sleep 3
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent
sleep 3

# El proceso se mostrara paso a paso para identificacion de posibles fallas
set -x

# 5. Descarga YARA y sus dependencias 
sudo apt install -y make gcc autoconf libtool libssl-dev pkg-config jq
sudo curl -LO https://github.com/VirusTotal/yara/archive/v4.2.3.tar.gz
sudo tar -xvzf v4.2.3.tar.gz -C /usr/local/bin/ && rm -f v4.2.3.tar.gz
cd /usr/local/bin/yara-4.2.3/
sudo ./bootstrap.sh && sudo ./configure && sudo make && sudo make install && sudo make check
sleep 5
sudo echo "/usr/local/lib" >> /etc/ld.so.conf
sleep 3
ldconfig

# 6. Preparación de reglas Yara
sudo apt-get update
sudo mkdir -p /var/ossec/yara/rules
sudo chmod 771 /var/ossec/yara/rules

# 7. Clonar el repositorio de Git en /var/ossec/yara
git clone https://github.com/Yara-Rules/rules.git /var/ossec/yara/rules
sleep 1
# Archivo de reglas YARA de Vallhala
sudo curl 'https://valhalla.nextron-systems.com/api/v1/get' \
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
-H 'Accept-Language: en-US,en;q=0.5' \
--compressed \
-H 'Referer: https://valhalla.nextron-systems.com/' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' \
--data 'demo=demo&apikey=1111111111111111111111111111111111111111111111111111111111111111&format=text' \
-o /var/ossec/yara/rules/yara_rules.yar

# 8. Ejecución del script para generar indices de reglas yara
cd /var/ossec/yara/rules/
/var/ossec/yara/rules/index_gen.sh

# 9. Eliminar el archivo de reglas YARA especificado
rm -rf /var/ossec/yara/rules/malware/MALW_AZORULT.yar
# Eliminar la línea exacta include "./malware/MALW_AZORULT.yar" del archivo index.yar que provoca conflicto con algunas versiones
sed -i '/include "\.\/malware\/MALW_AZORULT\.yar"/d' /var/ossec/yara/rules/index.yar

# 10. Configuracion interna del agente.
wazuh_agent="/var/ossec/etc/local_internal_options.conf"
lines_to_add=("logcollector.max_lines=3000" "wazuh_modules.max_eps=150" "logcollector.remote_commands=1" "wazuh_command.remote_commands=1")
# Agregar las líneas al final del archivo usando sed -i
for line in "${lines_to_add[@]}"; do
    echo "$line" >> "$wazuh_agent"
done
sleep 2

# 11. Deshabilitar repositorio de wazuh para evitar actualizaciones no programadas
sed -i "s/^deb/#deb/" /etc/apt/sources.list.d/wazuh.list
apt-get update

# 12. Verificar copia de script de integración yara
sudo cp yara.sh /var/ossec/active-response/bin/
sudo ls -lh /var/ossec/active-response/bin/
```

El script de generación de indices para Yara complementa las reglas descritas en el repositorio de Github con las reglas Yara utilizadas para la prueba de concepto y se incluye en la descarga del repositorio en el paso 7 del script de instalación.

```
/*
Generated by Yara-Rules
On 19-04-2024
*/
include "./antidebug_antivm/antidebug_antivm.yar"
include "./capabilities/capabilities.yar"
include "./crypto/crypto_signatures.yar"
include "./cve_rules/CVE-2010-0805.yar"
include "./cve_rules/CVE-2010-0887.yar"
.
.
.
include "./yara_rules.yar"
```

Pasada la primera etapa se configura el archivo ossec.conf del agente en /var/ossec/etc/ossec.conf dentro del modulo de syscheck.

```shell
<syscheck>

...
<directories realtime=\"yes\">Directorio_Monitorizado</directories>
...

</syscheck>
```

Reinicio del agente

```shell
sudo systemctl restart wazuh-agent
```

Comprobación del estado del agente

```shell
sudo systemctl status wazuh-agent
```

Se sugiere la modificación del script de yara para que se dirija al nuevo archivo de reglas que resulta ser index.yar.

```bash
#!/bin/bash
# Wazuh - Yara active response
# Copyright (C) 2015-2022, Wazuh Inc.
# This program is free software; you can redistribute it
# and/or modify it under the terms of the GNU General Public
# License (version 2) as published by the FSF - Free Software
# Foundation.
#------------------------- Gather parameters -------------------------#
# Extra arguments
read INPUT_JSON
#YARA_PATH=$(echo $INPUT_JSON | jq -r .parameters.extra_args[1])
#YARA_RULES=$(echo $INPUT_JSON | jq -r .parameters.extra_args[3])
YARA_PATH="/usr/local/bin/yara-4.2.3"
YARA_RULES="/var/ossec/yara/rules/index.yar"
FILENAME=$(echo $INPUT_JSON | jq -r .parameters.alert.syscheck.path)

# Set LOG_FILE path
LOG_FILE="logs/active-responses.log"
size=0
actual_size=$(stat -c %s ${FILENAME})
while [ ${size} -ne ${actual_size} ]; do
    sleep 1
    size=${actual_size}
    actual_size=$(stat -c %s ${FILENAME})
done
#----------------------- Analyze parameters -----------------------#
if [[ ! $YARA_PATH ]] || [[ ! $YARA_RULES ]]
then
    echo "wazuh-yara: ERROR - Yara active response error. Yara path and rules parameters are mandatory." >> ${LOG_FILE}
    exit 1
fi
#------------------------- Main workflow --------------------------#
# Execute Yara scan on the specified filename
yara_output="$("${YARA_PATH}"/yara -w -r "$YARA_RULES" "$FILENAME")"
if [[ $yara_output != "" ]]
then
    # Iterate every detected rule and append it to the LOG_FILE
    while read -r line; do
        echo "wazuh-yara: INFO - Scan result: $line" >> ${LOG_FILE}
    done <<< "$yara_output"
fi
exit 0;

```

En el script se modificaron los parámetros de YARA\_PATH y YARA\_RULES de acuerdo a la version de yara en path, y al nuevo archivo de reglas en YARA\_RULES.

# Webinar instalación y configuración de Wazuh manager

Durante el webinar se realizó la instalación del servidor de Wazuh en maquinas virtuales de Virtual-Box para realizar las distintas pruebas de concepto definiendo los parámetros a configurar en cada una de ellas y realizando el ejemplo para los agentes en terminales Linux y Windows.

Las configuraciones de los terminales y el servidor, así como el desarrollo de las 2 sesiones del webinar se encuentran a disposición en el siguiente enlace:

- [https://intranet.agetic.gob.bo/nube/s/qske4wdHrgofA7k](https://intranet.agetic.gob.bo/nube/s/qske4wdHrgofA7k)

# Monitoreo y Alertas de Seguridad en WordPress con Wazuh

#### <span style="color: rgb(35, 111, 161);">ANÁLISIS DE REGISTROS WEB EN WORDPRESS</span>

Los registros de acceso web en WordPress contienen información valiosa sobre las interacciones de los usuarios, acciones administrativas y posibles intentos de intrusión. El análisis detallado de estos logs permite identificar patrones de comportamiento legítimo, así como actividades, subidas de archivos no autorizados o explotación de vulnerabilidades en endpoints críticos.

Para ello desarrollamos una guía práctica utilizando Wazuh Manager como SIEM, para la creación de reglas personalizadas de detección, basadas en eventos locales y ataques previamente identificados en el entorno. Estas reglas permitirán:

- Detección de intentos de intrusión (fuerza bruta, subidas de archivos maliciosos, comportamiento anómalo).
- Monitoreo de accesos sospechosos a terminales desde el panel de administración (wp-admin).
- Generación de alertas tempranas ante comportamientos anómalos (Solicitudes AJAX múltiples desde la misma IP, modificaciones no autorizadas en la biblioteca de medios).

A partir de casos reales, se almacenaron distintos tipos de peticiones analizadas múltiples servidores, se establecerán criterios para identificar amenazas. El objetivo final es fortalecer la seguridad del sitio WordPress mediante un sistema de monitoreo proactivo, adaptado a necesidades específicas.

Puedes consultar la guía de instalación de Wazuh en el siguiente enlace: [Instalación de Wazuh Open Source Security – Base de Conocimiento CGII](https://www.cgii.gob.bo/bookstack/books/manuales-y-guias-de-seguridad/page/instalacion-wazuh-open-source-security)

#### <span style="color: rgb(35, 111, 161);">Escaneo de Vulnerabilidades en WordPress Usando Wazuh</span>

##### <span style="color: rgb(35, 111, 161);">Configuración de WP-CLI</span>

Para que Wazuh pueda interactuar con WordPress y realizar la comprobación de seguridad, es necesario instalar <span class="notion-enable-hover" data-token-index="1">WP-CLI</span> en el servidor. Sigue estos pasos: Descargar e instalar WP-CLI:

```
curl -O <https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar>
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
```

##### <span class="notion-enable-hover" data-token-index="0" style="color: rgb(35, 111, 161);">Creación de Políticas de Seguridad para WordPress</span>

La comprobación de seguridad en WordPress se basa en la aplicación de políticas definidas en un archivo YAML. A continuación, se describe cómo crearlas e implementarlas en Wazuh.

```bash
sudo su
mkdir /home/local_sca_policies/
touch /home/local_sca_policies/custom_wordpress_policy.yml
nano /home/local_sca_policies/custom_wordpress_policy.yml
```

Creamos nuestras propias reglas/políticas que debe cumplir Wazuh, definiendo cada una en el archivo `custom_wordpress_policy.yml`.

```yaml
# Security Configuration Assessment
# Hardening policies for WordPress installations

policy:
  id: "wordpress_assessment"
  file: "custom_wordpress_policy.yml"
  name: "Comprobación de configuración de seguridad para instalaciones de WordPress."
  description: "Guía para establecer una configuración segura en instalaciones de WordPress."
  references:
    - https://wordpress.org/support/article/hardening-wordpress/
    - https://wpsecuritychecklist.org/items/

requirements:
  title: "Verificar que el endpoint sea un host de WordPress y que tenga instalada la herramienta wp-cli."
  description: "Requisitos para ejecutar el escaneo de SCA contra la política de configuración de WordPress."
  condition: all
  rules:
    - 'f:$wp_install_dir/wp-config.php'
    - 'c:wp --info --allow-root -> r:^WP\pCLI\sversion\p'

variables:
  $wp_install_dir: /var/www/html # Example: /var/www/html
  $wp_host:  http://172.19.0.5:8000/ # Examples: https://example.com 
  $wp_user: admin # Example: admin
  $wp_security_plugin: wordfence # Example: wordfence 

checks:

```

En `checks`, agregamos las siguientes líneas, que explicaremos a continuación:

**<span style="color: rgb(35, 111, 161);">Regla 1. ID=100000</span>**

- **Propósito:** Evitar exploits en versiones antiguas con vulnerabilidades conocidas (CVE).
- **Cuándo actúa:** Cuando la versión instalada es inferior a la última estable publicada en [wordpress.org](http://wordpress.org).
- **Acción:** Actualizar WordPress a la última versión estable disponible.

```yaml
  - id: 100000
    title: "Fortalecimiento de WordPress: Asegurar que la versión de WordPress esté actualizada."
    description: "La versión instalada de WordPress debe ser la última versión disponible en https://wordpress.org/download/."
    rationale: "Pueden descubrirse nuevas vulnerabilidades en WordPress. Es importante actualizar a la última versión para evitar que se exploten vulnerabilidades descubiertas en versiones antiguas."
    remediation: "Actualizar WordPress a la última versión."
    condition: all
    rules:
      - c:runuser -l $wp_user -c "wp core check-update --path=$wp_install_dir" -> r:WordPress\sis\sat\sthe\slatest\sversion
```

**<span style="color: rgb(35, 111, 161);">Regla 2. ID=100001</span>**

- **Propósito:** Establecer permisos adecuados en el archivo `.htaccess`.
- **Condición:** Cuando los permisos del archivo `.htaccess` no son 644.
- **Acción:** Establecer los permisos del archivo `.htaccess` a 644.

```yaml
- id: 100001
    title: "Fortalecimiento de WordPress: Asegurar que los permisos del archivo .htaccess estén configurados en 644."
    description: "Esta política verifica los permisos del archivo .htaccess en el directorio raíz de la instalación de WordPress."
    rationale: "Usuarios no autorizados podrían leer el archivo .htaccess si los permisos no son lo suficientemente estrictos. Además, permisos demasiado restrictivos pueden causar errores al cargar un sitio de WordPress."
    remediation: "Establecer los permisos del archivo en 644 ejecutando el comando chmod 644 $wp_install_dir/.htaccess"
    condition: all
    rules:
      - c:stat -c '%a' $wp_install_dir/.htaccess -> r:644
```

**<span style="color: rgb(35, 111, 161);">Regla 3. ID=100002</span>**

- **Propósito**: Desactivar la depuración en WordPress.
- **Condición**: Si la constante WP\_DEBUG en wp-config.php está configurada como true.
- **Acción**: Configurar la constante WP\_DEBUG como false en el archivo wp-config.php.

```yaml
  - id: 100002
    title: "Fortalecimiento de WordPress: Asegurar que la depuración de WordPress esté desactivada."
    description: "Esta política verifica si la depuración de WordPress está habilitada en el archivo wp-config.php."
    rationale: "Cuando WP_DEBUG está habilitado, se muestra información detallada sobre errores en las páginas del sitio web. Esto puede incluir información sobre errores, funciones obsoletas y código vulnerable que puede ser explotado por actores maliciosos."
    remediation: "Desactivar la depuración de WordPress estableciendo la variable WP_DEBUG en wp-config.php en false."
    condition: none
    rules:
      - c:runuser -l $wp_user -c "wp config list WP_DEBUG --path=$wp_install_dir" -> r:true|1
```

**<span style="color: rgb(35, 111, 161);">Regla 4. ID=100003</span>**

- **Propósito**: Eliminar archivos de respaldo no necesarios.
- **Condición**: Si existen archivos <span class="notion-enable-hover" data-token-index="1" spellcheck="false">.zip</span>, <span class="notion-enable-hover" data-token-index="3" spellcheck="false">.bak</span>, <span class="notion-enable-hover" data-token-index="5" spellcheck="false">.old</span>, etc., en el directorio raíz.
- **Acción**: Eliminar archivos de respaldo no necesarios del directorio raíz.

```yaml
 - id: 100003
    title: "Fortalecimiento de WordPress: Asegurar que no haya archivos de respaldo (.zip, .back, .bac, .old) en el directorio raíz de la instalación de WordPress."
    description: "Esta política verifica si hay archivos de respaldo o comprimidos del sitio web o plugins en el directorio raíz de la instalación de WordPress."
    rationale: "Se pueden crear archivos de respaldo de algunos archivos de configuración sensibles, como wp-config.php.bak, antes de editar la configuración en vivo. Dado que estos archivos ya no terminan en .php, no son procesados por el motor de PHP y pueden ser leídos por cualquiera. Esto puede llevar a la divulgación de información sensible."
    remediation: "Realizar una limpieza de medios para eliminar bases de datos, archivos antiguos y de respaldo. Además, dejar solo los archivos necesarios en el directorio raíz de la instalación de WordPress."
    condition: none
    rules:
      - c:sh -c "cd $wp_install_dir; ls -la" -> r:.zip|.back|.backup|.bak|.old|.previous|.sql

```

**<span style="color: rgb(35, 111, 161);">Regla 5. ID=100004</span>**

- **Propósito**: Asegurar la seguridad de las cuentas administrativas.
- **Condición**: Si hay cuentas administrativas con nombres comunes (<span class="notion-enable-hover" data-token-index="1" spellcheck="false">admin</span>, <span class="notion-enable-hover" data-token-index="3" spellcheck="false">webmaster</span>, etc.).
- **Acción**: Renombrar las cuentas administrativas que utilizan nombres comunes por otros menos predecibles.

```yaml
  - id: 100004
    title: "Fortalecimiento de WordPress: Asegurar que no se utilicen nombres de cuentas administrativas comunes."
    description: "Esta política verifica si se utilizan nombres de cuentas administrativas comunes (por ejemplo, admin, administrator, webmaster)."
    rationale: "El uso de nombres de cuentas administrativas comunes aumenta la probabilidad de un ataque de fuerza bruta exitoso."
    remediation: "Renombrar todas las cuentas administrativas predeterminadas y utilizar nombres de cuentas administrativas poco comunes."
    condition: none
    rules:
      - c:runuser -l $wp_user -c "wp user list --field=user_login --path=$wp_install_dir" -> r:admin|administrator|backup|webmaster

```

**<span style="color: rgb(35, 111, 161);">Regla 6. ID=100005</span>**

- **Propósito**: Deshabilitar la navegación de directorios.
- **Condición**: Si no está configurada la directiva Options -Indexes en el archivo .htaccess.
- **Acción**: Agregar la directiva Options -Indexes en el archivo .htaccess.

```yaml

  - id: 100005
    title: "Fortalecimiento de WordPress: Asegurar que la navegación de directorios esté deshabilitada."
    description: "Esta política verifica si se puede listar el contenido de directorios sensibles (por ejemplo, wp-includes, wp-admin, wp-content)."
    rationale: "Cuando la navegación de directorios está habilitada en un servidor web, puede llevar a la divulgación de información sensible y permitir el listado del contenido de directorios privilegiados."
    remediation: "Deshabilitar la navegación de directorios agregando 'Options All -Indexes' en el archivo .htaccess de esta instalación de WordPress."
    condition: all
    rules:
      - c:cat $wp_install_dir/.htaccess -> r:Options\sAll\s\.Indexes
```

**<span style="color: rgb(35, 111, 161);">Regla 7. ID=100006</span>**

- **Propósito**: Establecer los permisos de las carpetas principales.
- **Condición**: Si los permisos de las carpetas principales (wp-admin, wp-includes, wp-content) no son 755.
- **Acción**: Establecer los permisos de las carpetas principales a 755.

```yaml
  - id: 100006
    title: "Fortalecimiento de WordPress: Asegurar que los permisos de las carpetas de WordPress estén configurados en 755."
    description: "Esta política verifica los permisos de las carpetas en las instalaciones de WordPress."
    rationale: "El uso de permisos incorrectos en las carpetas de una instalación de WordPress puede dejar los archivos en esos directorios expuestos a modificaciones no autorizadas."
    remediation: "Establecer todas las carpetas en el directorio de WordPress en 755 usando el comando chmod."
    condition: all
    rules:
      - c:stat -c '%a' $wp_install_dir/wp-admin -> r:755
      - c:stat -c '%a' $wp_install_dir/wp-includes -> r:755
      - c:stat -c '%a' $wp_install_dir/wp-content -> r:755
      - c:stat -c '%a' $wp_install_dir/wp-content/plugins -> r:755
      - c:stat -c '%a' $wp_install_dir/wp-content/themes -> r:755
```

**<span style="color: rgb(35, 111, 161);">Regla 8. ID=100007</span>**

- **Propósito**: Evitar exploits por temas desactualizados.
- **Condición**: Si hay temas con actualizaciones pendientes.
- **Acción**: Actualizar temas automáticamente.

```yaml
  - id: 100007
    title: "Fortalecimiento de WordPress: Asegurar que no haya plugins desactualizados."
    description: "Esta política verifica que no haya plugins de WordPress desactualizados en esta instalación de WordPress."
    rationale: "Los plugins desactualizados pueden tener vulnerabilidades que actores maliciosos pueden explotar para tomar el control de un sitio de WordPress y, posteriormente, del servidor."
    remediation: "Actualizar todos los plugins de WordPress."
    condition: none
    rules:
      - c:runuser -l $wp_user -c "wp plugin list --field=update --path=$wp_install_dir" -> r:available
```

**<span style="color: rgb(35, 111, 161);">Regla 9. ID=100008</span>**

- **Propósito**: Proteger el sitio con un plugin de seguridad.
- **Condición**: Si el plugin $wp\_security\_plugin no está activo.
- **Acción**: Activar el plugin de seguridad.

```yaml
  - id: 100008
    title: "Fortalecimiento de WordPress: Asegurar que no haya temas de WordPress desactualizados."
    description: "Esta política verifica que no haya temas de WordPress desactualizados en esta instalación de WordPress."
    rationale: "Los temas desactualizados pueden tener vulnerabilidades que actores maliciosos pueden explotar para tomar el control de un sitio de WordPress y, posteriormente, del servidor."
    remediation: "Actualizar todos los temas de WordPress."
    condition: none
    rules:
      - c:runuser -l $wp_user -c "wp theme list --field=update --path=$wp_install_dir" -> r:available
```

**<span style="color: rgb(35, 111, 161);">Regla 10. ID=100009</span>**

- **Propósito**: Reforzar la seguridad básica del sitio con herramientas especializadas.
- **Condición**: Si el plugin de seguridad definido en `$wp_security_plugin` no está activo.
- **Acción**: Instalar y activar el plugin de seguridad configurado (ej: Wordfence, Sucuri.

```yaml
- id: 100009
    title: "Fortalecimiento de WordPress: Asegurar que un plugin de seguridad esté instalado y activo."
    description: "Esta política verifica si el plugin de seguridad de WordPress especificado por la organización ($wp_security_plugin) está instalado."
    rationale: "Los plugins de seguridad pueden proporcionar una medida de protección contra exploits comunes dirigidos a sitios web de WordPress, como ataques de fuerza bruta e inyecciones SQL. La presencia de un plugin de seguridad reducirá significativamente la superficie de ataque."
    remediation: "Instalar y activar el plugin de seguridad $wp_security_plugin."
    condition: all
    rules:
      - c:runuser -l $wp_user -c "wp plugin is-active $wp_security_plugin --path=$wp_install_dir; echo $?" -> r:0

```

**<span style="color: rgb(35, 111, 161);">Regla 11. ID=100010</span>**

- **Propósito**: Proteger información sensible en el archivo de configuración
- **Condición**: Si `wp-config.php` es accesible desde el navegador (HTTP 200)
- **Acción**: Configurar el servidor web para denegar acceso a `wp-config.php` (HTTP 403/404).

```yaml
  - id: 100010
    title: "Fortalecimiento de WordPress: Asegurar que el archivo wp-config.php no sea accesible públicamente."
    description: "Esta política verifica si el archivo wp-config.php es accesible desde el navegador."
    rationale: "El archivo wp-config.php contiene credenciales y configuraciones críticas. Si es accesible públicamente, un atacante podría extraer información sensible."
    remediation: "Asegurar que el servidor web bloquea el acceso a wp-config.php mediante reglas en .htaccess o configuración de Nginx."
    condition: all
    rules:
      - c:curl -I $wp_host/wp-config.php -> r:403|404
```

**<span style="color: rgb(35, 111, 161);">Regla 12. ID=100011</span>**

- **Propósito: Eliminar vectores de ataque a través de XML-RPC**
- **Cuándo actúa: Si `xmlrpc.php` responde a solicitudes (no devuelve 403/404).**.
- **Acción:** Bloquear acceso al archivo.

```yaml
- id: 100011
    title: "Verificar si xmlrpc.php está accesible desde la web."
    description: "Si xmlrpc.php responde a solicitudes HTTP, podría ser un riesgo de seguridad."
    rationale: "Si este archivo no es necesario, es recomendable bloquear el acceso desde el servidor web."
    remediation: "Bloquear el acceso a xmlrpc.php en el servidor web configurando las reglas adecuadas en .htaccess o nginx."
    condition: all
```

**<span style="color: rgb(35, 111, 161);">Regla 13. ID=100012</span>**

- **Propósito:** Evitar la enumeración de usuarios a través de la API REST.
- **Cuándo actúa:** Si `/wp-json/wp/v2/users` expone nombres de usuario o IDs.
- **Acción:** Restringir el endpoint con autenticación o deshabilitarlo.

```yaml
 - id: 100012
    title: "Verificar si la API REST de WordPress expone usuarios."
    description: "Si el endpoint /wp-json/wp/v2/users devuelve datos en JSON y no un error de acceso, los nombres de usuario pueden ser extraídos."
    rationale: "Exponer usuarios a través de la API REST facilita ataques de fuerza bruta y enumeración de cuentas."
    remediation: "Restringir el acceso al endpoint o deshabilitar la API REST si no es necesaria."
    condition: all
    rules:
      - c:curl -s $wp_host/wp-json/wp/v2/users | grep -E '"id":| "name":' -> r:.*
```

<span style="color: rgb(35, 111, 161);">**Configurar el Agente de Wazuh**</span>

<span style="color: rgb(0, 0, 0);">Para que Wazuh pueda realizar el análisis de seguridad en la instalación de WordPress, es necesario configurar el agente en el servidor para que envíe los registros hacia el servidor y sea procesado.</span>

Editar la configuración del agente para habilitar el análisis SCA:

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

[![image (1).png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/scaled-1680-/J4IR8ZjZvIM5ppLD-image-1.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/J4IR8ZjZvIM5ppLD-image-1.png)

Agregar la configuración necesaria dentro del archivo de configuración del agente:

```xml
<policies>
    <policy>/home/local_sca_policies/custom_wordpress_policy.yml</policy>
</policies>
```

[![image (2).png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/scaled-1680-/1Ev4k83Opw1KitRU-image-2.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/1Ev4k83Opw1KitRU-image-2.png)

Reiniciar el agente de Wazuh para aplicar los cambios:

```bash
/var/ossec/bin/wazuh-control restart
```

[![image (3).png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/scaled-1680-/GnIVn7mqzqJClI2L-image-3.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/GnIVn7mqzqJClI2L-image-3.png)

##### <span style="color: rgb(35, 111, 161);">**Verificación de Resultados**</span>

Una vez configurado el análisis de seguridad en Wazuh, puedes verificar los resultados desde la interfaz gráfica.

- Accede a la interfaz de Wazuh.
- Navega a Security Configuration Assessment.

[![image (4).png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/scaled-1680-/Po7KnMc3Tn6J3oWD-image-4.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/Po7KnMc3Tn6J3oWD-image-4.png)

- Revisa los resultados del módulo SCA de seguridad en WordPress.

[![image (5).png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/scaled-1680-/lxysW7Da62dXgR9U-image-5.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/lxysW7Da62dXgR9U-image-5.png)

- Aplica las recomendaciones de Wazuh para corregir vulnerabilidades identificadas.

[![image (6).png](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/scaled-1680-/CCE2PGYFLspXtxMY-image-6.png)](https://www.cgii.gob.bo/bookstack/uploads/images/gallery/2025-03/CCE2PGYFLspXtxMY-image-6.png)

#### <span style="color: rgb(35, 111, 161);">Alertas de Wazuh en Wordpress</span>

##### <span style="color: rgb(35, 111, 161);">CREACIÓN DE REGLAS PERSONALIZADAS.  
</span>

A continuación explicaremos la creación de reglas personalizadas que responderán ante distintos casos de intentos de intrusión.

Nos dirigimos al archivo *local\_rules*

```bash
sudo nano /var/ossec/etc/rules/local_rules.xml
```

Para identificar distintos patrones de comportamiento anómalo en nuestro servidor, editamos el archivo con las siguientes reglas personalizadas. Es importante tener en cuenta que dichas reglas deben estar incluidas en un grupo para garantizar el orden y facilitar su visualización.

<span style="color: rgb(35, 111, 161);">**Regla 1. ID=100010**</span>

- **Eventos reconocidos:** Intentos de acceso a wp-admin mediante cualquier método HTTP.
- **Ayuda a identificar:** Posibles intentos de autenticación fallida o accesos no autorizados.
- **Cuándo se aplica:** Cuando hay tráfico dirigido a la URL wp-admin.
- **Regla en formato XML:**

```xml
<rule id="100010" level="6">
  <if_sid>31100,31101,31108</if_sid>
  <url>wp-admin</url>
  <protocol>GET|POST|PUT|DELETE</protocol>
  <description>Intento de acceso a wp-admin desde $(srcip)</description>
  <group>wordpress,authentication_failed,</group>
</rule>
```

<span style="color: rgb(35, 111, 161);">**Regla 2. ID=100011**</span>

- **Eventos reconocidos:** Subidas de archivos mediante async-upload.php usando métodos POST o PUT.
- **Ayuda a identificar:** Posibles intentos de subida de archivos maliciosos a través de WordPress.
- **Cuándo se aplica:** Cuando se detecta tráfico hacia wp-admin/async-upload.php.
- **Regla en formato XML:**

```xml
<rule id="100011" level="6">
  <if_sid>100010</if_sid>
  <url>/wp-admin/async-upload.php</url>
  <protocol>POST|PUT</protocol>
  <description>Subida de archivos mediante async-upload de WordPress desde $(srcip)</description>
  <group>wordpress,authentication_failed,</group>
</rule>
```

<span style="color: rgb(35, 111, 161);">**Regla 3. ID=100012**</span>

- **Eventos reconocidos:** Peticiones a admin-ajax.php con métodos POST o PUT.
- **Ayuda a identificar:** Uso potencial de acciones AJAX en el administrador de WordPress, que pueden ser explotadas por atacantes.
- **Cuándo se aplica:** Cuando se detecta tráfico hacia  
    ```
     wp-admin/admin-ajax.php.
    ```
- **Regla en formato XML:**

```xml
<rule id="100012" level="6">
  <if_sid>100010</if_sid>
  <url>/wp-admin/admin-ajax.php</url>
  <protocol>POST|PUT</protocol>
  <description>Ejecución de una acción AJAX en el panel de administración desde $(srcip)</description>
  <group>wordpress,authentication_failed,</group>
</rule>
```

<span style="color: rgb(35, 111, 161);">**Regla 4. ID=100013**</span>

- **Eventos reconocidos:** Múltiples intentos de acceso fallidos a wp-admin en un corto período (20 intentos en 120 segundos).
- **Ayuda a identificar:** Ataques de fuerza bruta contra la autenticación de WordPress.
- **Cuándo se aplica:** Cuando se detectan múltiples intentos desde la misma IP en un tiempo determinado.
- **Regla en formato XML:**

```xml
<rule id="100013" level="11" frequency="20" timeframe="120">
  <if_matched_sid>100010</if_matched_sid>
  <same_source_ip />
  <description>Múltiples intentos de acceso a wp-admin desde $(srcip)</description>
  <mitre>
    <id>T1110</id>
    <id>T1110.001</id>
  </mitre>
  <group>attack,brute_force,wordpress,web,</group>
</rule>
```

<span style="color: rgb(35, 111, 161);">**Regla 5. ID=100014**</span>

- **Eventos reconocidos:** Accesos a directorios de plugins de WordPress mediante patrones en la URL.
- **Ayuda a identificar:** Posibles exploraciones en busca de vulnerabilidades en plugins.
- **Cuándo se aplica:** Cuando una URL coincide con
    
    ```
    /wp-content/plugins/([^/]+)/.
    ```
- **Regla en formato XML:**

```xml
<rule id="100014" level="8">
  <if_sid>31103</if_sid>
  <url type="pcre2">/wp-content/plugins/([^/]+)/</url>
  <description>Acceso a plugin WordPress posiblemente vulnerable: $(url) desde $(srcip)</description>
  <mitre>
    <id>T1190</id>
  </mitre>
</rule>
```

<span style="color: rgb(35, 111, 161);">**Regla 6. ID=100015**</span>

- **Eventos reconocidos:** Modificación del archivo wp-config.php.
- **Ayuda a identificar:** Alteraciones en un archivo crítico que podrían indicar una intrusión.
- **Cuándo se aplica:** Cuando se detecta un cambio en
    
    ```
    /var/www/html/wp-config.php.
    ```
- **Regla en formato XML:**

```xml
<rule id="100015" level="10">
  <if_group>syscheck</if_group>
  <field name="file">/var/www/html/wp-config.php</field>
  <description>Cambio detectado en archivo crítico wp-config.php</description>
</rule>
```

# Alertas de Wazuh en Wordpress

##### <span style="color: rgb(35, 111, 161);">ANÁLISIS DE REGISTROS WEB EN WORDPRESS</span>

Los registros de acceso web en WordPress contienen información valiosa sobre las interacciones de los usuarios, acciones administrativas y posibles intentos de intrusión. El análisis detallado de estos logs permite identificar patrones de comportamiento legítimo, así como actividades, subidas de archivos no autorizados o explotación de vulnerabilidades en endpoints críticos.

Para ello desarrollamos una guía práctica utilizando Wazuh Manager como SIEM, para la creación de reglas personalizadas de detección, basadas en eventos locales y ataques previamente identificados en el entorno. Estas reglas permitirán:

- Detección de intentos de intrusión (fuerza bruta, subidas de archivos maliciosos, comportamiento anómalo).
- Monitoreo de accesos sospechosos a terminales desde el panel de administración (wp-admin).
- Generación de alertas tempranas ante comportamientos anómalos (Solicitudes AJAX múltiples desde la misma IP, modificaciones no autorizadas en la biblioteca de medios).

A partir de casos reales, se almacenaron distintos tipos de peticiones analizadas múltiples servidores, se establecerán criterios para identificar amenazas. El objetivo final es fortalecer la seguridad del sitio WordPress mediante un sistema de monitoreo proactivo, adaptado a necesidades específicas.

##### <span style="color: rgb(35, 111, 161);">CREACIÓN DE REGLAS PERSONALIZADAS.  
</span>

A continuación explicaremos la creación de reglas personalizadas que responderán ante distintos casos de intentos de intrusión.

Nos dirigimos al archivo *local\_rules*

```bash
sudo nano /var/ossec/etc/rules/local_rules.xml
```

Para identificar distintos patrones de comportamiento anómalo en nuestro servidor, editamos el archivo con las siguientes reglas personalizadas. Es importante tener en cuenta que dichas reglas deben estar incluidas en un grupo para garantizar el orden y facilitar su visualización.

<span style="color: rgb(35, 111, 161);">**Regla 1. ID=100010**</span>

- **Eventos reconocidos:** Intentos de acceso a wp-admin mediante cualquier método HTTP.
- **Ayuda a identificar:** Posibles intentos de autenticación fallida o accesos no autorizados.
- **Cuándo se aplica:** Cuando hay tráfico dirigido a la URL wp-admin.
- **Regla en formato XML:**

```xml
<rule id="100010" level="6">
  <if_sid>31100,31101,31108</if_sid>
  <url>wp-admin</url>
  <protocol>GET|POST|PUT|DELETE</protocol>
  <description>Intento de acceso a wp-admin desde $(srcip)</description>
  <group>wordpress,authentication_failed,</group>
</rule>
```

<span style="color: rgb(35, 111, 161);">**Regla 2. ID=100011**</span>

- **Eventos reconocidos:** Subidas de archivos mediante async-upload.php usando métodos POST o PUT.
- **Ayuda a identificar:** Posibles intentos de subida de archivos maliciosos a través de WordPress.
- **Cuándo se aplica:** Cuando se detecta tráfico hacia wp-admin/async-upload.php.
- **Regla en formato XML:**

```xml
<rule id="100011" level="6">
  <if_sid>100010</if_sid>
  <url>/wp-admin/async-upload.php</url>
  <protocol>POST|PUT</protocol>
  <description>Subida de archivos mediante async-upload de WordPress desde $(srcip)</description>
  <group>wordpress,authentication_failed,</group>
</rule>
```

<span style="color: rgb(35, 111, 161);">**Regla 3. ID=100012**</span>

- **Eventos reconocidos:** Peticiones a admin-ajax.php con métodos POST o PUT.
- **Ayuda a identificar:** Uso potencial de acciones AJAX en el administrador de WordPress, que pueden ser explotadas por atacantes.
- **Cuándo se aplica:** Cuando se detecta tráfico hacia  
    ```
     wp-admin/admin-ajax.php.
    ```
- **Regla en formato XML:**

```xml
<rule id="100012" level="6">
  <if_sid>100010</if_sid>
  <url>/wp-admin/admin-ajax.php</url>
  <protocol>POST|PUT</protocol>
  <description>Ejecución de una acción AJAX en el panel de administración desde $(srcip)</description>
  <group>wordpress,authentication_failed,</group>
</rule>
```

<span style="color: rgb(35, 111, 161);">**Regla 4. ID=100013**</span>

- **Eventos reconocidos:** Múltiples intentos de acceso fallidos a wp-admin en un corto período (20 intentos en 120 segundos).
- **Ayuda a identificar:** Ataques de fuerza bruta contra la autenticación de WordPress.
- **Cuándo se aplica:** Cuando se detectan múltiples intentos desde la misma IP en un tiempo determinado.
- **Regla en formato XML:**

```xml
<rule id="100013" level="11" frequency="20" timeframe="120">
  <if_matched_sid>100010</if_matched_sid>
  <same_source_ip />
  <description>Múltiples intentos de acceso a wp-admin desde $(srcip)</description>
  <mitre>
    <id>T1110</id>
    <id>T1110.001</id>
  </mitre>
  <group>attack,brute_force,wordpress,web,</group>
</rule>
```

<span style="color: rgb(35, 111, 161);">**Regla 5. ID=100014**</span>

- **Eventos reconocidos:** Accesos a directorios de plugins de WordPress mediante patrones en la URL.
- **Ayuda a identificar:** Posibles exploraciones en busca de vulnerabilidades en plugins.
- **Cuándo se aplica:** Cuando una URL coincide con
    
    ```
    /wp-content/plugins/([^/]+)/.
    ```
- **Regla en formato XML:**

```xml
<rule id="100014" level="8">
  <if_sid>31103</if_sid>
  <url type="pcre2">/wp-content/plugins/([^/]+)/</url>
  <description>Acceso a plugin WordPress posiblemente vulnerable: $(url) desde $(srcip)</description>
  <mitre>
    <id>T1190</id>
  </mitre>
</rule>
```

<span style="color: rgb(35, 111, 161);">**Regla 6. ID=100015**</span>

- **Eventos reconocidos:** Modificación del archivo wp-config.php.
- **Ayuda a identificar:** Alteraciones en un archivo crítico que podrían indicar una intrusión.
- **Cuándo se aplica:** Cuando se detecta un cambio en
    
    ```
    /var/www/html/wp-config.php.
    ```
- **Regla en formato XML:**

```xml
<rule id="100015" level="10">
  <if_group>syscheck</if_group>
  <field name="file">/var/www/html/wp-config.php</field>
  <description>Cambio detectado en archivo crítico wp-config.php</description>
</rule>
```