Este proyecto tiene como objetivo mostrar la configuración e integración de Wazuh en un entorno profesional para mejorar las operaciones de seguridad. Aquí, vamos a ver cómo instalar, gestionar agentes, configurar de alertas para luego integrarlas con Microsoft Teams y, finalmente, pruebas con Atomic Red Team para validación.

Instalación

Para alojar nuestro servidor de Wazuh, usaremos una instancia en AWS EC2 con Ubuntu 24.04. Esta configuración nos da flexibilidad, escalabilidad y facilidad de mantenimiento en una infraestructura basada en la nube.

Una vez que nuestro servidor esté actualizado, ejecutamos el siguiente comando para instalar Wazuh:

1curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

Esto se encargará de la configuración e instalación de todos los componentes principales. El proceso comienza verificando los requisitos del sistema e instalando dependencias. Luego, el script configura la seguridad de Wazuh generando certificados para los componentes de root, administrador, indexador, Filebeat y panel de control, asegurando el manejo seguro de datos en todo el ecosistema.

Una vez configuradas las dependencias y configuraciones, el script instala y arranca secuencialmente los servicios clave de Wazuh: el Wazuh Indexer para almacenamiento de datos, el Wazuh Manager para detección de amenazas, Filebeat para el reenvío de logs y el Wazuh Dashboard para monitoreo. El panel es accesible en https://<ip-servidor-wazuh>:443 con las credenciales proporcionadas al final del script de instalación.

Cuando iniciamos sesión en nuestro panel de control de Wazuh por primera vez, debemos comenzar configurando grupos para facilitar la gestión de agentes.

Para crear grupos de agentes desde el panel de Wazuh:

1. Navega a Management > Groups y haz clic en el botón Add new group.
2. Introduce un nombre para el grupo de agentes y haz clic en el botón Save new group.

Ahora pasaremos al despliegue de nuestros agentes.

Despliegue de Agentes

Para agregar un nuevo agente, hacemos clic en el menú y vamos a Endpoints Summary y seleccionamos Deploy new agent. Sigue las instrucciones del asistente para desplegar un agente:

Si estás configurando un agente de Wazuh en una instancia EC2 de AWS y experimentas problemas de conectividad, revisa la configuración del grupo de seguridad aplicado a tu instancia y asegúrate de que el Security Group adjunto a tu instancia de Wazuh manager permita el tráfico entrante en estos puertos:

• 1514/TCP – Comunicación del agente
• 1515/TCP – Registro del agente
• 55000/TCP – Acceso API

Añadí como primer agente una instancia de AWS Lightsail que quiero monitorear. Ahora podemos avanzar a configuraciones adicionales, como detección de vulnerabilidades y rootkits, monitoreo de integridad de archivos, etc.

Detección de Vulnerabilidades

A la fecha de publicación, Wazuh viene por defecto con el módulo de detección de vulnerabilidades activado. Para confirmarlo, revisa el archivo de configuración ubicado en /var/ossec/etc/ossec.conf

 1<vulnerability-detection>
 2   <enabled>yes</enabled>
 3   <index-status>yes</index-status>
 4   <feed-update-interval>60m</feed-update-interval>
 5</vulnerability-detection>
 6
 7<indexer>
 8   <enabled>yes</enabled>
 9   <hosts>
10      <host>https://0.0.0.0:9200</host>
11   </hosts>
12   <ssl>
13      <certificate_authorities>
14         <ca>/etc/filebeat/certs/root-ca.pem</ca>
15      </certificate_authorities>
16      <certificate>/etc/filebeat/certs/filebeat.pem</certificate>
17      <key>/etc/filebeat/certs/filebeat-key.pem</key>
18   </ssl>
19</indexer>

Para verificar las vulnerabilidades detectadas en nuestros agentes, vamos a Threat Intelligence > Vulnerability Detection.

Alertas

El configurar alertas en Wazuh involucra establecer umbrales de alerta, enviar alertas a sistemas externos y gestionar la escalada y filtrado de alertas.

Umbrales

Wazuh asigna un nivel de gravedad (de 0 a 15) a cada evento en base a reglas predefinidas. Por defecto, Wazuh activa alertas para eventos con un nivel de gravedad de 3 o superior. Puedes ajustar este umbral para controlar qué alertas se generan.

Para modificarlo, ve al archivo ossec.conf, ubica la sección <alerts> y ajusta el valor de <log_alert_level> al umbral deseado.

Por ejemplo, para establecer el nivel mínimo de alerta en 5:

1<alerts>
2  <log_alert_level>5</log_alert_level>
3</alerts>

Después de realizar cambios en el archivo de configuración, reinicia Wazuh manager para aplicar los nuevos ajustes con:

1sudo systemctl restart wazuh-manager

Filtrado de Alertas

Para optimizar el sistema de alertas, se puede implementar reglas de filtrado de alertas en Wazuh para suprimir eventos específicos, como intentos de fuerza bruta SSH hacia usuarios inexistentes. Sigue estos pasos:

1. Identifica el ID de la Regla: Determina el ID de la regla asociada con la alerta que deseas anular. Puedes encontrar este ID en los registros de alertas o revisando el conjunto de reglas de Wazuh.

   • Para intentos de fuerza bruta en SSH en Linux, puedes encontrar estos eventos con rule.id:(5551 OR 5712). Otras reglas relacionadas son 5710, 5711, 5716, 5720, 5503, 5504.

   • Para fallos de inicio de sesión en Windows, puedes encontrar esos eventos con rule.id:(60122 OR 60204).

2. Crea una Regla Local para Anular Alertas: Creando una regla local con un nivel de severidad más bajo, puedes evitar que la alerta sea enviada.

   • Navega al directorio de reglas de Wazuh, ubicado en /var/ossec/etc/rules/local_rules.xml.

   • Agrega la siguiente regla para suprimir la alerta específica:

     1<group name="sshd,">
     2  <rule id="100002" level="0">
     3    <if_sid>5716</if_sid>
     4    <description>Ignorar alertas de fuerza bruta SSH hacia usuarios inexistentes</description>
     5  </rule>
     6</group>

     Esta regla establece el nivel de alerta en 0 para el evento especificado, suprimiéndolo. Para un ejemplo más detallado, consulta el archivo de ejemplo de ossec.

3. Reinicia el Administrador de Wazuh: Aplica los cambios reiniciando Wazuh manager:

   1sudo systemctl restart wazuh-manager

Reenvío de Alertas

Wazuh puede reenviar alertas a varios sistemas externos, como servidores syslog, direcciones de correo electrónico o plataformas de colaboración como Microsoft Teams.

• Para reenviar alertas a un servidor syslog, agrega un bloque <syslog_output> en el archivo ossec.conf:

1<syslog_output>
2  <server>192.168.1.241</server>
3  <level>9</level>
4</syslog_output>

Esta configuración envía alertas con un nivel de gravedad superior a 9 al servidor syslog especificado.

• Para recibir alertas por correo electrónico, configura los ajustes de correo en la sección <global> de ossec.conf:

 1<ossec_config>
 2  <global>
 3    <email_notification>yes</email_notification>
 4    <email_to>me@test.com</email_to>
 5    <smtp_server>mail.test.com</smtp_server>
 6    <email_from>wazuh@test.com</email_from>
 7  </global>
 8  <alerts>
 9    <email_alert_level>10</email_alert_level>
10  </alerts>
11</ossec_config>

Esta configuración envía alertas por correo para eventos con un nivel de gravedad de 10 o superior.

Integración con Teams

Para integrar las alertas de Wazuh con Microsoft Teams, tenemos varias opciones: usar el Webhook de Teams, Zapier, Make.com u otra plataforma similar para enviar alertas a un canal de Teams mediante un webhook. Esto implica crear un script de integración personalizado y configurarlo en ossec.conf.

Usaré esta integración ya configurada con Teams, creada por @redanthrax.

Una vez configurada la integración en el servidor Wazuh, simplemente configúralo así:

1<integration>
2  <name>custom-teams</name>
3  <level>3</level>
4  <hook_url>{WEBHOOK URL}</hook_url> 
5  <alert_format>json</alert_format> 
6</integration>

Ahora recibiremos alertas en un canal de Teams en cada alerta de nivel 3:

Para extender estas alertas, podemos implementar un sistema SOAR para automatizar la priorización, crear procesos de escalamiento, desarrollar playbooks y respuestas a incidentes. Podríamos usar otra buena solución de código abierto como Shuffle para esto.

Pruebas y Validación

Para validar nuestra implementación de Wazuh y asegurarnos de que las alertas se activen correctamente, usaremos Atomic Red Team, un framework versátil y de código abierto que nos permite simular técnicas de ataque reales mapeadas al marco ATT&CK de MITRE. Específicamente, utilizaremos el módulo PowerShell Invoke-Atomic, que se puede ejecutar en Windows, MacOS y Linux, siendo una herramienta ideal para probar en todos nuestros agentes.

Configuración de Atomic Red Team

Hagamos algunas pruebas en nuestro servidor Ubuntu. Primero instalaremos PowerShell en Linux con sudo snap install powershell --classic y luego ejecutaremos pwsh. Una vez dentro de PowerShell, podemos proceder a instalar tanto el framework de ejecución como la carpeta de pruebas atómicas, que contiene las definiciones de las pruebas; los comandos que el marco de ejecución ejecutará.

1IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing);
2Install-AtomicRedTeam -getAtomics

Ahora podemos utilizar la función Invoke-AtomicTest para realizar pruebas de seguridad controladas. A continuación pongo ejemplos de técnicas específicas de MITRE ATT&CK que podemos ejecutar para probar nuestra configuración:

• Prueba para Transferencia de Herramientas de Ingreso (T1105): Simula un intento de transferir archivos desde una fuente remota a un entorno, lo que podría ser indicativo de una descarga de malware o exfiltración de datos. Esta actividad debería activar alertas si Wazuh monitorea adecuadamente la actividad de red y movimiento de archivos.

  1Invoke-AtomicTest T1105

• Prueba de Volcado de Credenciales (T1003): Ejecuta una simulación de volcado de credenciales para verificar si Wazuh captura eventos potenciales de acceso a credenciales.

  1Invoke-AtomicTest T1003.008 # OS Credential Dumping: /etc/passwd and /etc/shadow

• Prueba de Creación de Tareas Programadas (T1053): Usa tareas programadas para simular técnicas de persistencia y verificar si Wazuh alerta sobre la creación de tareas.

  1Invoke-AtomicTest T1053.003 # Scheduled Task/Job: Cron

• Prueba de Ejecución de Intérprete de Comandos y Scripts (T1059): Simula actividad de scripting sospechosa que Wazuh debería detectar según los ajustes de umbral.

  1Invoke-AtomicTest T1059.004 # Command and Scripting Interpreter: Unix Shell

Verificación de Alertas en Wazuh

Después de ejecutar cada prueba, navegaremos al panel de Wazuh para verificar las alertas generadas. Podemos ver los eventos correspondientes a cada prueba de Atomic Red Team en Threat Intelligence > MITRE ATT&CK. Podemos revisar los detalles para confirmar que las alertas coinciden con los umbrales configurados según lo previsto.

Al completar la implementación, configuración y validación de Wazuh, hemos creado una configuración de SIEM sólida y proactiva capaz de detectar, alertar y responder a eventos de seguridad de manera efectiva. Con integraciones para una alerta fluida, monitoreo de vulnerabilidades y pruebas con Atomic Red Team, este despliegue de Wazuh fortalece nuestra postura de seguridad organizacional. A medida que evolucionan las amenazas, esta configuración puede personalizarse aún más para satisfacer las necesidades dinámicas de las operaciones de seguridad modernas, convirtiéndola en un activo valioso en el conjunto de herramientas de nuestro SOC. Este proyecto destaca el poder de las soluciones de código abierto como Wazuh para construir un entorno de ciberseguridad resiliente y adaptable.