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
- Actualización Wazuh Manager
- Pruebas de concepto (PDC)
- Envío de alertas por correo Wazuh manager
- Monitoreo de actividad con usuarios en agentes
- Envío de alertas mediante bot de Telegram
- Análisis de logs en Bases de datos
- Integración con antivirus ClamAV
- Integración complementaria de reglas YARA
- Webinar instalación y configuración de Wazuh manager
- Comprobación de Seguridad en WordPress con Wazuh
- Alertas de Wazuh en Wordpress
Instalación Wazuh Open Source security
Introducción.
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.
Instalación de Wazuh.
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:
Requisitos.
Hardware.
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:
Compatibilidad del navegador.
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.
Instalación rápida Wazuh Manager.
Ejecución del asistente de instalación de Wazuh.
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh && sudo bash ./wazuh-install.sh -a
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://<wazuh-dashboard-ip> (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.
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:
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txtInstalación del agente de Wazuh.
En caso de no tener instalado el paquete 'curl' se debe proceder con la instalación del mismo para realizar la descarga de elementos.
sudo apt install curlInstalación de claves GPG
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.gpgAñadir el repositorio de Wazuh a las listas de repositorios.
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.listActualizar la información de los paquetes.
apt-get updateDESPLIEGUE 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:
Con el asistente tenemos los comandos a insertar en el terminal del nuevo agente por lo que procedemos a copiar los comandos generados:
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.
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.
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.
sudo systemctl stop wazuh-manager
sudo systemctl stop wazuh-dashboard
sudo systemctl stop wazuh-indexersudo systemctl status wazuh-manager
sudo systemctl status wazuh-dashboard
sudo systemctl status wazuh-indexer
Posteriormente realizamos una actualización de los repositorios.
sudo apt-get updateListamos los paquetes que pueden actualizarse para encontrar wazuh-dashboard, wazuh-indexer y wazuh-manager en la lista.
sudo apt list --upgradable
Por ultimo realizamos la actualización de paquetes con el comando upgrade.
sudo apt upgradeDurante 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.
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-homeEl 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:
--- /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--- /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
--- /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.
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.pemCambiamos la lista de permisos.
sudo chown wazuh-dashboard:wazuh-dashboard /etc/wazuh-dashboard/certs/*.pem
sudo chmod 600 /etc/wazuh-dashboard/certs/*.pemVerificamos la configuración de la API por el puerto "55000".
sudo nano /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.ymlhosts:
- default:
url: https://127.0.0.1
port: 55000
username: wazuh-wui
password: "Contraseña Wazuh-Wui"
run_as: falsePor último para la cantidad de memoria RAM asignada para los procesos modificamos el archivo:
sudo nano /etc/wazuh-indexer/jvm.optionsDentro 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.
sudo chmod -R 755 /usr/share/wazuh-indexer
sudo chown -R wazuh-indexer:wazuh-indexer /usr/share/wazuh-indexerRealizamos un "restart" a cada uno de los componentes de Wazuh para aplicar los cambios y esperamos aproximadamente 2 minutos para utilizar los servicios.
sudo systemctl daemon-reload
sudo systemctl restart wazuh-manager
sudo systemctl restart wazuh-dashboard
sudo systemctl restart wazuh-indexersudo systemctl status wazuh-manager
sudo systemctl status wazuh-dashboard
sudo systemctl status wazuh-indexer
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.
sudo rebootIngresamos al dashboard y verificamos que la versión de Wazuh se actualizó con éxito.
Pruebas de concepto (PDC)
PDC 1: BLOQUEO DE DIRECCIÓN IP MALICIOSA CONOCIDA.
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.
| TERMINAL |
DESCRIPCIÓN |
| Debian | 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. |
| Ubuntu | 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. |
Configuración.
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:
sudo apt update && sudo apt install -y wgetDescargue la base de datos de reputación de IP de Alienvault:
sudo wget https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/alienvault_reputation.ipset -O /var/ossec/etc/lists/alienvault_reputation.ipsetAgregamos 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).
sudo echo 192.168.24.73 >> /var/ossec/etc/lists/alienvault_reputation.ipsetDescargamos 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).
sudo wget https://wazuh.com/resources/iplist-to-cdblist.py -O /tmp/iplist-to-cdblist.pyConvertimos el archivo “alienvault_reputation.ipset” a un formato “.cdb” usando el script descargado previamente:
sudo /var/ossec/framework/python/bin/python3 /tmp/iplist-to-cdblist.py /var/ossec/etc/lists/alienvault_reputation.ipset /var/ossec/etc/lists/blacklist-alienvaultEliminamos “alienvault_reputation.ipset” y el script “iplist-to-cdblist.py”, para que no sean usados erronea o de forma maliciosa.
sudo rm -rf /var/ossec/etc/lists/alienvault_reputation.ipset
sudo rm -rf /tmp/iplist-to-cdblist.pyAsignamos los permisos y la propiedad correctos al archivo generado:
sudo chown wazuh:wazuh /var/ossec/etc/lists/blacklist-alienvaultLa 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.
sudo nano /var/ossec/etc/rules/local_rules.xmlEn el archivo de conjunto de reglas personalizado del servidor Wazuh:
<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.
sudo nano /var/ossec/etc/ossec.confPara que se pueda comparar con la lista de direcciones de alienvault agregamos la lista creada “etc/lists/blacklist-alienvault” a la sección “<ruleset>”.
<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):
sudo nano /var/ossec/etc/ossec.confSe debe quitar el símbolo de comentario al apartado <active-response> y escribir de acuerdo al ID de la regla creada en este caso 100100.
<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:
sudo nano /var/ossec/etc/ossec.conf<localfile>
<log_format>syslog</log_format>
<location>/var/log/apache2/access.log</location>
</localfile>Emulación del ataque.
Para la emulación de ataque se debe acceder al servidor web desde el extremo Kali utilizando la dirección IP correspondiente:
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.
Resultados.
Posteriormente Wazuh manager bloquea el intento de acceso y el servidor se hace inaccesible por parte del atacante.
PDC 2: MONITOREO DE INTEGRIDAD DE ARCHIVOS.
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.
Configuración.
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 <syscheck> directorios para ser monitoreados (se puede configurar cualquier ruta en específico).
sudo nano /var/ossec/etc/ossec.conf<directories check_all="yes" report_changes="yes" realtime="yes">/root</directories>Reiniciamos para aplicar los cambios.
sudo systemctl restart wazuh-agentEmulación del ataque.
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.
cd /root/
touch archivo.txtAgregue contenido al archivo de texto y guárdelo.
echo "contenido de archivo" >> archivo.txtElimine el archivo de texto del directorio supervisado.
rm archivo.txtResultados.
Con la creación del archivo se genera una alerta de nivel 3 ya que el archivo esta vacío.
La modificación del archivo genera una alerta de nivel 8 al ser un directorio importante para ser monitorizado.
Por ultimo se genera la alerta de eliminación del archivo de nivel 7.
PDC 3: ATAQUE DE FUERZA BRUTA.
| TERMINAL |
DESCRIPCIÓN |
| Debian |
Terminal del atacante que realiza ataques de fuerza bruta. Con SSH instalado. |
| Ubuntu |
Terminal víctima de ataques de fuerza bruta SSH. Es necesario tener un servidor SSH instalado y habilitado en este punto final. |
Configuración:
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.
sudo apt update
sudo apt install -y hydraEmulación del ataque
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.
sudo nano PASSWD_LIST.txt123456
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.
sudo hydra -l xubuntu -P PASSWD_LIST.txt 192.168.24.72 sshResultados.
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.
PDC 4: DETECCIÓN DE PROCESOS NO AUTORIZADOS.
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.
Configuración.
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:
sudo nano /var/ossec/etc/ossec.conf<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.
sudo systemctl restart wazuh-agentPosteriormente instalamos Netcat para realizar las pruebas.
sudo apt install ncat nmap -yServidor 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:
sudo nano /var/ossec/etc/rules/local_rules.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.
sudo systemctl restart wazuh-managerEmulación de ataque.
Ejecutamos en el terminal el siguiente comando durante aproximadamente 30 segundos.
nc -l 8000Este 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.
Resultados.
El servidor de Wazuh manager nos mostrara el siguiente evento:
PDC 5:INTEGRACIÓN DE IDS DE RED.
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.
Configuración
Realizamos la instalación de Suricata en Debian.
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt-get update
sudo apt-get install suricata -ySeguidamente 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.
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/*.rulesUna vez extraídos se debe modificar la configuración en el archivo “.yaml”
sudo nano /etc/suricata/suricata.yamlHOME_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: enp0s18El nombre de la interface se obtiene con el comando:
ip address showReiniciar el servicio de Suricata.
sudo systemctl restart suricataPara que el agente de Wazuh pueda leer el archivo de registros de Suricata se debe configurar el ossec.conf.
sudo nano /var/ossec/etc/ossec.conf<ossec_config>
<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>
</ossec_config>Para aplicar cambios se reinicia el agente de Wazuh.
sudo systemctl restart wazuh-agentEmulación del ataque.
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:
ping -c 20 192.168.24.87
Resultados.
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.
PDC 6: DETECCIÓN DE INYECCIÓN SQL.
| TERMINAL |
DESCRIPCIÓN |
| Debian |
Terminal atacante con payload de inyección SQL |
| Ubuntu |
Terminal víctima con servidor web Apache |
Configuración.
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.
sudo apt update
sudo apt install apache2Si el Firewall está habilitado, se debe modificar para permitir el acceso externo a los puertos web. Omita este paso si el Firewall está deshabilitado.
sudo ufw app list
sudo ufw allow 'Apache'
sudo ufw statusVerificar el estado del servicio Apache para ver que el servidor web se está ejecutando:
sudo systemctl status apache2Utilizar en consola curl o en su defecto abrir http://<UBUNTU_IP> -> http://192.168.24.73 en un navegador para ver la página de inicio de Apache y verificar la ejecución:
curl http://<UBUNTU_IP>En la parte del agente Wazuh agregue las siguientes líneas del archivo de configuración.
nano /var/ossec/etc/ossec.confEl siguiente comando permite al agente de Wazuh monitorear los registros de acceso de su servidor Apache y enviar registros continuamente a Wazuh manager:
<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:
sudo systemctl restart wazuh-agentEmulación del ataque.
Utilice el siguiente comando con la dirección IP adecuada del servidor y ejecute el siguiente comando desde el extremo del atacante:
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.
Resultados.
El resultado generó una alerta de intento de inyección SQL.
PDC 7: DETECCIÓN DE SUSPICIOUS BINARIES.
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.
Configuración.
De forma predeterminada, el módulo rootcheck de Wazuh está habilitado en el archivo de configuración del agente de Wazuh.
Verifique el apartado <rootcheck> en el archivo de configuración del terminal monitoreado y asegurarse que la configuración este dada de la siguiente manera
sudo nano /var/ossec/etc/ossec.conf<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>Emulación de ataque.
Creamos una copia del sistema binario original con:
sudo cp -p /usr/bin/w /usr/bin/w.copyEjecute el comando
sudo chmod +x /usr/bin/w.copyEste da permisos de ejecución a la copia creada.
Reemplace el sistema binario original /usr/bin/w con el siguiente script de 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
EOFEste 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.
sudo systemctl restart wazuh-agentResultados.
Mientras tanto Wazuh manager nos da como resultado la siguiente respuesta:
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.
sudo rm /usr/bin/wSe debe restaurar la copia del binario original.
sudo mv /usr/bin/w.copy /usr/bin/wPor ultimo eliminar el archivo que creó el script de shell.
sudo rm /tmp/trojan_created_fileVerifique que el binario original funcione correctamente con el comando w los resultados serán los siguientes en caso de estar restablecido.
PDC 8: DETECCIÓN Y ELIMINACIÓN DE MALWARE MEDIANTE INTEGRACIÓN CON VIRUS TOTAL.
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.
Configuración.
Agregue las siguientes reglas al archivo local de reglas.
sudo nano /var/ossec/etc/rules/local_rules.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.
sudo nano /var/ossec/etc/ossec.confSe 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 <ossec_config> </ossec_config>.
<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
sudo nano /var/ossec/etc/ossec.conf<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:
sudo nano /var/ossec/etc/rules/local_rules.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.
systemctl restart wazuh-managerPara esta prueba de concepto la maquina vulnerable es Debian linux en la cual realizaremos las siguientes configuraciones:
sudo nano /var/ossec/etc/ossec.confDentro del archivo de configuración <disabled> se establece en no, permitiendo que Wazuh FIM controle los cambios de directorio.
<syscheck>
<disabled>no</disabled>Agregar una entrada dentro del apartado <syscheck> para configurar un directorio para ser monitoreado casi en tiempo real. En este caso se está monitoreando el directorio /root.
<directories realtime="yes">/root</directories>Instalar “jq” la cual es una utilidad que procesa la entrada JSON del script de respuesta activo.
sudo apt update
sudo apt -y install jqCreamos 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.
#!/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.
sudo chmod 750 /var/ossec/active-response/bin/remove-threat.shCambiamos el propietario del archivo para que Wazuh pueda ejecutar el script en caso de alertas activas.
sudo chown root:wazuh /var/ossec/active-response/bin/remove-threat.shPara aplicar estos cambios reiniciamos el agente.
sudo systemctl restart wazuh-agentEmulación del ataque.
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:
sudo cd /root
sudo curl -LO https://secure.eicar.org/eicar.com && ls -lah eicar.comEsperamos 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.
Resultados.
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:
PDC 9: DETECCIÓN DE VULNERABILIDADES.
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.
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.
Configuración.
Nos dirigimos al directorio /var/ossec/etc/ossec.conf para realizar las siguientes modificaciones, dentro del apartado "<ossec_config>"
<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>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.
<!-- 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>Se utiliza el formato OS_name-OS_majorcon separados por comas y el atributo allow para incluir el sistema operativo. Para aplicar los cambios reiniciamos Wazuh manager.
sudo systemctl restart wazuh-managerEn 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.
sudo apt install sqlite3Seguidamente para abrir la base de datos de vulnerabilidades:
sqlite3 /var/ossec/queue/vulnerabilities/cve.dbListamos las tablas en la base de datos.
sqlite> .tablesPara visualizar las tablas, Ej:
sqlite> select * from <table>;El servidor de Wazuh crea automáticamente la base de datos de vulnerabilidad global con datos de los siguientes repositorios:
- https://canonical.com : se usa para extraer CVE para distribuciones Ubuntu Linux.
- https://www.redhat.com : se utiliza para extraer CVE para las distribuciones Red Hat y CentOS Linux.
- https://www.debian.org : se usa para extraer CVE para las distribuciones de Debian Linux.
- https://security.archlinux.org : se usa para extraer CVE para las distribuciones de Arch Linux.
- https://nvd.nist.gov : se usa para extraer CVE de la base de datos nacional de vulnerabilidad.
- https://feed.wazuh.com : se utiliza para obtener actualizaciones de seguridad de Microsoft (MSU) y fuentes ALAS.
Los feeds 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.
PDC 10: DETECCIÓN DE MALWARE INTEGRACIÓN CON YARA.
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.
Configuración.
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:
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 checkVerificamos la instalación
yara*El siguiente error aparece en distribuciones de Ubuntu.
/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.
sudo echo "/usr/local/lib" >> /etc/ld.so.conf
ldconfigUna vez solucionado el error o si este no se encuentra la respuesta del terminal deberia ser de la siguiente manera:
yara
Proseguimos a descargar las reglas de detección de malware en Yara
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.yarSe debe crear un archivo yara.sh
#!/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;nano /var/ossec/active-response/bin/yara.shPor último cambiamos el propietario del archivo para que root:wazuh lo pueda manejar:
sudo chown root:wazuh /var/ossec/active-response/bin/yara.sh
sudo chmod 750 /var/ossec/active-response/bin/yara.shAgregar que dentro del bloque <syscheck> del agente Wazuh en el archivo de configuración este configurado para monitorear el directorio /tmp/yara/malware:
nano /var/ossec/etc/ossec.conf<directories realtime="yes">/tmp/yara/malware</directories>Reiniciar el agente de Wazuh
sudo systemctl restart wazuh-agentEn el servidor de Wazuh tenemos que agregar eventos para extraer la información y los resultados de Yara.
nano /var/ossec/etc/rules/local_rules.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.
<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:
nano /var/ossec/etc/decoders/local_decoder.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>Emulación del ataque.
Crear el archivo /tmp/yara/malware/malware_downloader.sh en el punto final monitoreado para descargar muestras de malware.
touch /tmp/yara/malware/malware_downloader.sh
nano /tmp/yara/malware/malware_downloader.sh#!/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
fiEjecutamos el script malware_downloader.sh para descargar muestras de malware al directorio /tmp/yara/malware.
sudo bash /tmp/yara/malware/malware_downloader.shResultado.
Filtramos las alertas por rule.groups yara
PDC 11: DETECCIÓN DE PROCESOS OCULTOS.
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.
Configuración.
Para realizar el cometido primero realizamos los siguientes pasos desde el terminal:
sudo apt updateInstalamos los paquetes necesarios para el rootkit
sudo apt -y install gcc gitConfiguramos el agente de Wazuh para ejecutar el escaneo de verificación de raíz cada 2 minutos.
En el archivo ossec.conf
sudo nano /var/ossec/etc/ossec.confSeleccionamos frequency en 120 para realizar el análisis cada 2 minutos:
<frequency>120</frequency> Reiniciamos el agente de Wazuh para aplicar los cambios.
systemctl restart wazuh-agentEmulación del ataque.
Obtenemos un código de rootkit desde Diamorphine de GitHub.
git clone https://github.com/m0nad/Diamorphinecd /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.
sudo apt-get install linux-headers-$(uname -r)Luego cargamos el módulo del kernel del rootkit.
insmod diamorphine.koSe 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.
lsmod | grep diamorphine
kill -63 509
lsmod | grep diamorphineSe 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.
ps auxw | grep rsyslogd | grep -v grepSi el proceso no ocasiona ninguna salida es que algunos paquetes no están instalados, se deben seguir las siguientes instrucciones:
sudo apt-get install linux-headers-$(uname -r)
sudo apt-get install rsyslog
systemctl restart rsyslog
systemctl status rsyslogUna vez instalados los paquetes tenemos:
ps auxw | grep rsyslogd | grep -v grepsalida:
root 22534 0.0 0.1 221772 6036 ? Ssl 16:34 0:00 /usr/sbin/rsyslogd -n -iNONEsudo kill -31 22534ps auxw | grep rsyslogd | grep -v grepEl 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.
Resultados.
Se pueden visualizar los datos de alerta en el panel de control de Wazuh.
Se realizo una detección de un posible rootkit.
Por seguridad se deben eliminar los archivos y la instalación del sistema de este rootkit para esto realizamos.
sudo rm -rf /var/ossec/etc/DiamorphinePDC 12: SUPERVISIÓN DE LA EJECUCIÓN DE COMANDOS MALICIOSOS.
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).
Configuración.
En el terminal final instalaremos Auditd posteriormente crearemos reglas para consultar todos los comandos ejecutados por un usuario con privilegios.
sudo apt -y install auditd
sudo systemctl start auditd
sudo systemctl enable auditdCon credenciales root ejecutamos los comandos para agregar reglas de auditoría al archivo /etc/audit/audit.rules
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.rulesCargamos las reglas para confirmar que están en el directorio correcto.
sudo auditctl -R /etc/audit/audit.rules
sudo auditctl -lDebemos agregar la siguiente configuración al archivo del agente permitiendo que el agente lea el archivo de registros auditados en el directorio:
sudo nano /var/ossec/etc/ossec.conf<localfile>
<log_format>audit</log_format>
<location>/var/log/audit/audit.log</location>
</localfile>Para efectuar los cambios reiniciamos el agente de Wazuh.
sudo systemctl restart wazuh-agentEn 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:commandCreamos una lista CDB y editamos el contenido /var/ossec/etc/lists/suspicious-programs
ncat:yellow
nc:red
tcpdump:orangeAgregamos la lista a la sección del archivo del servidor Wazuh en la sección <ruleset>
nano /var/ossec/etc/ossec.conf<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.
sudo nano /var/ossec/etc/rules/local_rules.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.
sudo systemctl restart wazuh-managerEmulación del ataque.
En el terminal de prueba utilizaremos un programa catalogado como “peligroso” intencionalmente con netcat.
sudo apt -y install netcat
nc -vResultados.
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.
PDC 13: DETECCIÓN DE UN ATAQUE DE SHELLSHOCK.
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.
Configuración.
En el terminal víctima se necesitan los paquetes actualizados del servidor Apache:
sudo apt update
sudo apt install apache2Si el firewall está activo debe modificarse para permitir el acceso externo a los puertos web.
sudo ufw app list
sudo ufw allow 'Apache'
sudo ufw statusComprobamos que el servidor está siendo ejecutado:
sudo systemctl status apache2Agregamos 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.
nano /var/ossec/etc/ossec.conf<localfile>
<log_format>syslog</log_format>
<location>/var/log/apache2/access.log</location>
</localfile>Para aplicar los cambios reiniciamos el agente de Wazuh.
sudo systemctl restart wazuh-agentEmulación del ataque.
La dirección IP del terminal (192.168.24.73) nos sirve para ejecutar el siguiente comando desde el terminal Debian del atacante.
sudo curl -H "User-Agent: () { :; }; /bin/cat /etc/passwd" 192.168.24.73El 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
Resultados.
Se detecta un ataque de shellshock con nivel de gravedad debido a que se realizaron algunos intentos.
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.
sudo nano /var/ossec/etc/ossec.conf<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.
<ossec_config>
<alerts>
<email_alert_level>12</email_alert_level>
</alerts>
</ossec_config>Para aplicar los cambios se debe reiniciar el servidor de Wazuh:
systemctl restart wazuh-managerPara 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.
sudo apt-get update && apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modulesPara configurar Postfix se debe crear el archivo main de configuración.
sudo nano /etc/postfix/main.cfrelayhost = [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_destinationEstablezca 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.
echo [smtp-mail.outlook.com]:587 correo@outlook.com:******** > /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
chmod 400 /etc/postfix/sasl_passwdCambiamos los permisos de base de datos de contraseña para que solo usuario root pueda verla.
chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.dbSe debe reiniciar Postfix para aplicar los cambios:
systemctl restart postfixPrueba 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:
echo "Prueba de correo electrónico" | mail -s "Prueba n°1" -r "correo_que_envia@outlook.com" correo_que_recibe@outlook.comEn la bandeja de entrada tenemos:
Con la prueba realizada se configuran las notificaciones por correo electrónico en el archivo de configuración de Wazuh.
sudo nano /var/ossec/etc/ossec.conf<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>
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:
systemctl restart wazuh-managerEl 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.
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.
nano /etc/rsyslog.confAgregamos al archivo:
auth,authpriv.* /var/log/auth.log
systemctl restart rsyslog.serviceEs recomendable quitar el comentario a la linea LogLevel para una información mas precisa.
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/1Introducimos 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.
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.
useradd cuatro
usermod -aG cuatro
userdel cuatroRevisamos 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:
En el caso del comando userdel tenemos:
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:
Realizamos la prueba en Decoders Test para verificar que se reconocen los parámetros.
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.
Una vez realizada esta regla probamos el log con Ruleset Test de Wazuh para ver si se genera de manera correcta.
Realizadas las pruebas utilizaremos la maquina virtual para proceder con la generación de alertas de niveles 8 y 10 respectivamente:
Usuario creado:
Escala de privilegios:
Eliminación de usuario:
En el agente de Wazuh agregamos este bloque en el archivo de configuración para monitorizar el archivo sudoers.
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:
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
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.
Como primer paso crearemos un bot de Telegram con la ayuda de BotFather.
Para crear el bot seguimos los siguientes comandos:
Crear bot:/newbot
Nos pedira darle un nombre al bot:wazuhbot2050_bot
Nos dara un número nuevo de API para el bot, la respuesta que en este caso es:ClaveAPI2050Alfanumerica
La clave API es muy importante por que se incluirá a los scripts de Wazuh manager y se utiliza para obtener el chat ID.
Utilizaremos un script en Wazuh manager de la siguiente manera:
sudo nano /var/ossec/integrations/custom-telegram#!/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} "$@"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 “-”.
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.
#!/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)nano /var/ossec/integrations/custom-telegram.pyEn 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”
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:
name: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-".hook_url: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.api_key :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.level :establece un filtro de nivel para que el script no reciba alertas por debajo de cierto nivel.rule_id :establece un filtro para los identificadores de alerta.group :Establece un filtro de grupo de alertas.event_location :establece un filtro de fuente de alerta.alert_format :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:
nano /var/ossec/etc/ossec.conf <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.
systemctl restart wazuh-managerEs 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.
Análisis de logs en Bases de datos
Mariadb para análisis de logs.
Actualización de los repositorios del sistema.
sudo apt-get updateActualización e instalación de MariaDB
sudo apt update
sudo apt install mariadb-server
sudo systemctl status mariadbUna vez instalada Mariadb comprobamos con el estatus:
Como no se tiene una configuración predeterminada de usuario ni password la contraseña esta vacía y el usuario por defecto es root. Ingresamos a la base de datos:
mysql -u root -pCreamos 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.
CREATE USER 'remoto'@'%' IDENTIFIED BY '1234';
grant all privileges on *.* to 'remoto'@'%' with grant option;Realizamos la creación del usuario saliendo de root e ingresando con usuario “remoto” de manera local.
MariaDB [(none)]>exit
mysql -u remoto -p
exitIngresamos de forma exitosa:
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.
nano /etc/mysql/mariadb.conf.d/50-server.cnf
Cabe destacar que esta configuración solo es recomendable para entornos de prueba, en un entorno de producción tenemos que restringir lo mas posible que dirección o direcciones IP pueden conectarse.
Reiniciamos Mariadb para aplicar los cambios.
sudo systemctl restart mariadbTenemos la direccion ip del servidor “192.168.24.84” con la que realizaremos la prueba remota desde nuestro terminal.
mysql -h 192.168.24.84 -P 3306 -u remoto -p
Para que se registren los logs de MariaDB se deben realizar cambios en el archivo de configuración quitando el símbolo de comentario en las siguientes lineas.
nano /etc/mysql/mariadb.conf.d/50-server.cnf
Los logs se registran en el directorio /var/lib/mysql/server_audit.log. Luego debemos instalar el plugging de auditoria en el servidor mariadb.
mysql -u remoto -pINSTALL 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 mariadbInstalación de rsyslog en nuestro servidor MariaDB.
sudo apt-get install -y rsyslogDespué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.
sudo nano /etc/rsyslog.conf
Para aplicar los cambios se debe reiniciar el servicio Rsyslog.
systemctl restart rsyslogSe debe habilitar el complemento de auditoria
nano /etc/mysql/my.cnf
Reiniciamos para aplicar los cambios
systemctl restart mariadbPara realizar una prueba usamos una contraseña incorrecta y correcta en repetidas ocasiones desde un terminal remoto:
mysql -h 192.168.24.84 -P 3306 -u remoto -pVerificamos el archivo de auditoria.
cat /var/log/mysql/mariadb-audit.log | grep remoto
Por ultimo verificamos el archivo syslog para confirmar que la información este correlacionada.
En el servidor configuramos la conexión remota con esta acción Wazuh también obtendrá registros de nuestro servidor MariaDB, para eso, necesitamos editar el archivo de configuración.
sudo nano /var/ossec/etc/ossec.conf<!-- 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>systemctl restart wazuh-manager.servicePara el archivo de logs en Wazuh, en el agente.
<!-- Registro de logs mariadb -->
<localfile>
<log_format>syslog</log_format>
<location>/var/log/mysql/mariadb-audit.log</location>
</localfile>nano /var/ossec/etc/rules/local_rules.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>systemctl restart wazuh-managerCon todas las configuraciones realizadas se pueden ver las alertas en el dashboard de Wazuh manager.
Elaboración de reglas en Wazuh manager para la auditoria de bases de datos.
El primer paso para las reglas personalizadas esta en el servidor de wazuh manager, ingresamos al archivo de configuración y añadimos el directorio de reglas personalizadas.
nano /var/ossec/etc/ossec.confDentro del archivo de configuración en <ossec_config> y <ruleset>
<ruleset>
<!-- Código anterior ... -->
<!-- Directorio de reglas locales de wazuh -->
<rule_dir>/var/ossec/etc/rules/local_rules.xml</rule_dir>
</ruleset>Decodificador para MariaDB
La creación de un decoder para Mariadb es necesaria para la interpretación de Wazuh manager para posteriormente crear alertas generadas por actividades realizadas dentro de las bases de datos.
Los tipos de logs de mariadb generados por el plugin de auditoria son de la siguiente manera:
- Para el caso de conexión fallida:
20240321 13:54:26,server2,remoto,192.168.24.68,45,0,FAILED_CONNECT,,,1045 - Para eliminación de base de datos y tablas
20240317 16:10:02,server2,remoto,192.168.24.68,31,65,QUERY,mysql,'drop database dbprueba',020240316 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:
<decoder name="mariadb-syslog">
<prematch>^(\d+ \d\d:\d\d:\d\d),</prematch>
<regex offset="after_prematch">^\w+,(\w+),(\S+),\d+,\d+,(\w+),</regex>
<order>dstuser,srcip,action</order>
</decoder>El nombre del decodificador es muy importante ya que tiene que pertenecer al grupo de decodificadores por defecto de Wazuh para que no entre en conflicto con los decodificadores que interpreta Wazuh manager si es que estos están dentro de los programas monitoreados por defecto.
Se realiza la prueba de este decodificador donde pre-match es la coincidencia de elementos al principio de cada log, y la parte de regex es la que nos importa para extraer los datos necesarios para nosotros, que se extraen en el apartado order.
Para verificar su funcionamiento tenemos una herramienta llamada decoders test en Wazuh manager que nos indica si los datos que necesitamos se pudieron extraer de forma correcta.
Podemos observar los tipos de logs generados por el plugin de auditoria de mariadb enviados a Wazuh manager para que sea decodificado por nuestro decodificador y posteriormente reconoce los datos requeridos como el nombre del decodificador, usuarios e IP proveniente.
Para la siguiente fase debemos crear reglas personalizadas a partir de estos decodificadores.
Reglas personalizadas para MariaDB.
Debemos crear una regla personalizada para que este detecte cuando una base de datos ha sido borrada. En este caso la regla se activa cuando Wazuh manager encuentra la palabras drop database, ingresamos al archivo de configuración.
nano /var/ossec/etc/rules/local_rules.xml
<!--
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
mysql -h 192.168.24.84 -P 3306 -u remoto -pSe crea una base de datos de prueba y se elimina.
Posteriormente observamos la alerta en Wazuh manager.
Posteriormente podemos realizar una regla mas en caso de que se elimine una tabla dentro de una base de datos:
Revisando las alertas generadas en el dashboard de Wazuh manager podemos observar una alerta de nivel 7 con la ubicación del archivo de log para obtener mas información.
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.
Configuración.
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.
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
Instalación de Rsyslog.
sudo apt-get install rsyslog -yConfiguración daemon de Clamav.
Modificar los datos en el archivo de configuración.
sudo nano /etc/clamav/clamd.confLogSyslog true
#LogFile /var/log/clamav/clamav.logsudo nano /etc/clamav/freshclam.confLogVerbose true
LogSyslog trueModificar los siguientes apartados en clamd.conf que es el scanner mediante linea de comandos.
sudo nano /usr/local/etc/clamd.conf# Comment or remove the line below.
# Examplesudo nano /usr/local/etc/freshclam.conf# Comment or remove the line below.
# Example
UpdateLogFile /var/log/clamav/freshclam.logsystemctl restart clamav-daemon
systemctl enable clamav-daemon
systemctl restart wazuh-agentsudo usermod -aG clamav $USER
sudo usermod -aG adm $USER
sudo chmod 666 /var/run/clamav/clamd.ctlComando de prueba para análisis y almacenamiento en syslog:
clamscan --stdout --no-summary -i -r /directorio/de/escaneo | logger -t "clamd[5286]"Comando de prueba para respuesta en consola de archivos infectados:
clamscan --stdout --no-summary -i -r /home/rchavez/Descargas/MalwareAgente 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.
nano /var/ossec/etc/ossec.conf <localfile>
<log_format>syslog</log_format>
<location>/var/log/syslog</location>
</localfile>systemctl restart wazuh-agentUna vez realizados los ajustes podemos observar diferentes tipos de alertas generadas.
Cuando se detiene el servicio de clamAV tenemos:
Cuando se detecta un archivo infectado tenemos:
Cuando se tiene un error inesperado o mala configuración tenemos:
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.
sudo nano /etc/clamav/freshclam.conf#Para una actualización de 6 veces al dia.
Checks 6sudo systemctl restart clamav-freshclamActualización manual de freshclam.
Configuración manual para actualizar clamav-freshclam realizando los siguientes siguientes comandos:
sudo systemctl stop clamav-freshclam.service
sudo freshclam
sudo systemctl restart clamav-freshclam.serviceProgramació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.
sudo su
crontab -eDentro 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.
#!/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.
<syscheck>
...
<directories realtime=\"yes\">Directorio_Monitorizado</directories>
...
</syscheck>Reinicio del agente
sudo systemctl restart wazuh-agentComprobación del estado del agente
sudo systemctl status wazuh-agentSe sugiere la modificación del script de yara para que se dirija al nuevo archivo de reglas que resulta ser index.yar.
#!/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:
Comprobación de Seguridad en WordPress con Wazuh
Introducción
En esta guía, aprenderás a configurar y utilizar Wazuh para comprobar la seguridad de una instalación de WordPress. Wazuh es una plataforma de seguridad de código abierto que permite realizar comprobaciones de la configuración de seguridad (SCA, Security Configuration Assessment) con el objetivo de identificar vulnerabilidades y configuraciones incorrectas en tu sitio de WordPress.
El uso de SCA en Wazuh facilita la detección de configuraciones débiles, permisos inadecuados, credenciales expuestas y otras fallas de seguridad que pueden comprometer un sitio web. A lo largo de esta guía, se explicarán los pasos necesarios para la instalación y configuración de Wazuh, la implementación del agente en el servidor donde se ejecuta WordPress y la correcta integración con WP-CLI, herramienta clave para gestionar WordPress desde la línea de comandos.
Requisitos Previos
Antes de comenzar, asegúrate de contar con los siguientes requisitos:
- Un servidor con WordPress instalado.
- Acceso root o permisos de administrador en el servidor.
- Docker instalado (si optas por la versión en contenedores de Wazuh).
- WP-CLI instalado en el servidor (herramienta de línea de comandos para administrar WordPress).
Instalación de Wazuh
Opción 1: Instalación en Docker
Si prefieres instalar Wazuh utilizando Docker, sigue estos pasos:
- Clonar el repositorio de Wazuh Docker:
git clone <https://github.com/wazuh/wazuh-docker.git> -b v4.9.2
cd wazuh-docker/single-node- Generar los certificados para el indexador:
sudo docker compose -f generate-indexer-certs.yml run --rm generator- Iniciar los contenedores de Wazuh:
sudo docker compose up -d- Acceder a la interfaz de Wazuh en el navegador:
https://localhost #credenciales por defecto admin:SecretPassword
Opción 2: Instalación mediante script de la documentación.
Si prefieres instalar Wazuh de manera manual, sigue la guía oficial proporcionada por la AGETIC:
Debes tomar en cuenta la recomendación de instalar siempre la última versión disponible de Wazuh y comenzar con la instalación con privilegios de root o un usuario sudo.
Configuración de WP-CLI
Para que Wazuh pueda interactuar con WordPress y realizar la comprobación de seguridad, es necesario instalar WP-CLI 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- Verificar que WP-CLI esté instalado correctamente:
wp --infoSi la instalación fue exitosa, deberías ver la versión de WP-CLI reflejada en la salida del comando.
Creación de Políticas de Seguridad para WordPress
Paso 1: Crear el Archivo de Políticas
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.
- Crear el Archivo de Políticas.
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- Añade el siguiente contenido al archivo para definir las reglas de seguridad que se comprobarán en tu sitio Wordpress:
# 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:
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
rules:
- c:curl -s -o /dev/null -w "%{http_code}" $wp_host/xmlrpc.php -> r:^(200|403)$
- 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:.* Este archivo establecerá las configuraciones que serán revisadas por Wazuh, como permisos de archivos, configuración de autenticación, cada regla tiene su información acerca de su funcionamiento en el apartado "description".
Paso 2: Configurar el Agente de Wazuh
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.
- Instalar el agente de Wazuh en el servidor:
wget <https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.9.2-1_amd64.deb>
sudo dpkg -i wazuh-agent_4.9.2-1_amd64.deb
sudo apt --fix-broken install- Editar la configuración del agente para habilitar el análisis SCA:
sudo nano /var/ossec/etc/ossec.conf
- Agregar la configuración necesaria dentro del archivo de configuración del agente:
<policies>
<policy>/home/local_sca_policies/custom_wordpress_policy.yml</policy>
</policies>
- Reiniciar el agente de Wazuh para aplicar los cambios:
/var/ossec/bin/wazuh-control restart
Verificación de Resultados
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.
- Revisa los resultados del módulo SCA de seguridad en WordPress.
- Aplica las recomendaciones de Wazuh para corregir vulnerabilidades identificadas.
Con esta guía, has aprendido a instalar y configurar Wazuh para comprobar la seguridad de una instalación de WordPress. Implementando las políticas de seguridad adecuadas y utilizando WP-CLI, puedes obtener información detallada sobre posibles vulnerabilidades y corregirlas a tiempo para fortalecer la seguridad de tu sitio.
Para obtener más información sobre la configuración avanzada de Wazuh, consulta la documentación oficial.
Recomendaciones.
- Mantén tu servidor de Wazuh actualizado para garantizar compatibilidad con nuevas versiones de WordPress.
- Verifica periódicamente los análisis SCA para detectar configuraciones inseguras antes de que puedan ser explotadas.
- No mantengas las configuraciones predeterminadas tras una instalación.
Alertas de Wazuh en Wordpress
ANÁLISIS DE REGISTROS WEB EN WORDPRESS
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.
CREACIÓN DE REGLAS PERSONALIZADAS.
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
sudo nano /var/ossec/etc/rules/local_rules.xmlPara 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.
Regla 1. ID=100010
- 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:
<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>Regla 2. ID=100011
- 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:
<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>Regla 3. ID=100012
- 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:
<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>Regla 4. ID=100013
- 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:
<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>Regla 5. ID=100014
-
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:
<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>Regla 6. ID=100015
-
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:
<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>