Armé un SIEM gratis con Wazuh y Kibana: así detecta un ataque de fuerza bruta en tiempo real

Santiago Ruiz Diaz — Sun, 06 Sep 2026 17:02:49 +0000

El problema que casi nadie mira hasta que es tarde

Trabajando en infraestructura para más de 25 sedes de una corporación, aprendí algo que se repite en todo el sector IT: el problema casi nunca es la falta de registros — es que nadie los revisa.

Cada servidor, cada firewall, cada endpoint genera logs de autenticación constantemente. La actividad sospechosa — alguien probando contraseñas contra un servidor, por ejemplo — casi siempre queda ahí, documentada, invisible, hasta que alguien mira.

Para una empresa grande, tener un SIEM (Security Information and Event Management) que centralice y correlacione esos logs es casi un estándar. Para una mipyme que recién está armando su infraestructura, comprar una licencia de SIEM comercial no es una opción realista.

Así que armé uno gratis, con herramientas open source, para mostrar exactamente qué se puede lograr sin gastar en licencias: Wazuh + Kibana, corriendo en Docker, detectando en tiempo real un intento de ataque de fuerza bruta simulado.

Acá el video de la demo (el mismo que publiqué en LinkedIn):
https://lnkd.in/p/dvQVub7W

Y acá abajo, el paso a paso completo — la arquitectura, la configuración real, y los problemas que me tocó resolver en el camino, porque casi ninguno de ellos aparece en la documentación oficial.

Arquitectura: qué es cada pieza

Wazuh se compone de tres servicios principales, todos corriendo en contenedores separados:

Wazuh Indexer: el motor de búsqueda/almacenamiento (basado en OpenSearch), donde viven los eventos y alertas
Wazuh Manager: el cerebro — recibe los eventos de los agentes, los procesa contra un set de reglas, y genera alertas
Wazuh Dashboard: la interfaz visual (basada en Kibana/OpenSearch Dashboards) para explorar todo

Además, cada endpoint que querés monitorear necesita un Wazuh Agent instalado — en mi caso, un contenedor separado simulando un servidor Linux, con el agente enrolado contra el manager.

┌─────────────┐ ┌──────────────┐ ┌────────────────┐
│ Wazuh Agent │ ───▶ │ Wazuh Manager │ ───▶ │ Wazuh Indexer │
│ (servidor │ │ (procesa │ │ (almacena │
│ monitoreado)│ │ reglas) │ │ eventos) │
└─────────────┘ └──────────────┘ └───────┬────────┘
│
┌───────▼────────┐
│ Wazuh Dashboard │
│ (visualización) │
└────────────────┘

Deploy del stack

Usé el repositorio oficial wazuh-docker (v4.14.7), que trae un docker-compose con los tres servicios y la generación de certificados TLS entre ellos ya resuelta.

Requisito previo en Windows: Docker Desktop necesita Hyper-V y Virtual Machine Platform habilitados. Si docker te tira que no detecta virtualización aunque esté prendida en la BIOS, revisá esto (en PowerShell, como administrador):

powershell
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart
bcdedit /set hypervisorlaunchtype auto

Reiniciar

Con eso resuelto, el stack completo levanta con docker compose up -d. Las credenciales por defecto del dashboard son admin / SecretPassword (cambiarlas es obligatorio en un despliegue real, esto es un lab).

El agente: acá está el 90% de los problemas reales

Levantar el stack central es la parte fácil. Lo que realmente cuesta — y donde se pierde más tiempo — es lograr que el agente realmente te mande los eventos que esperás.

Usé un contenedor wazuh/wazuh-agent:4.14.7 sobre una base amazonlinux:2023 simulando el servidor a monitorear, enrolado contra el manager vía el bloque <client><server> de ossec.conf.

Problema 1: el agente no mandaba nada

Primer bug real: rsyslog en el contenedor tenía imuxsock SysSock.Use="off" en su config. Como el contenedor no tiene systemd/journald corriendo, la ruta basada en journal quedaba vacía — el agente no tenía de dónde leer.

sed -i 's/SysSock.Use="off"/SysSock.Use="on"/' /etc/rsyslog.conf
# reiniciar rsyslogd

Problema 2: seguía sin monitorear el log correcto

Después de arreglar rsyslog, seguía sin aparecer nada. Revisando el propio ossec.log del agente, confirmé que nunca hubo una directiva <localfile> apuntando a /var/log/secure — el agente solo monitoreaba comandos y active-responses.log por defecto. Hubo que agregar explícitamente el bloque de monitoreo del log de autenticación y reiniciar.

Esta parte es la que más vale la pena remarcar: la documentación te dice cómo instalar el agente, no necesariamente qué vas a estar monitoreando realmente por default. Vale la pena verificar ossec.log en cualquier despliegue nuevo antes de asumir que "ya está andando".

Las reglas: cómo Wazuh arma la alerta de fuerza bruta

Un intento de login fallido individual genera una alerta de nivel bajo (regla 5760, sshd auth failed). Eso solo no dice mucho — cualquiera se equivoca tipeando una contraseña.

Lo interesante es la correlación: cuando Wazuh detecta varios intentos fallidos consecutivos desde el mismo origen en una ventana corta de tiempo, dispara la regla 2502, nivel 10 — fuerza bruta confirmada. Esto requiere al menos 3 intentos fallidos consecutivos para activarse; con 1 o 2 no correlaciona (lo confirmé revisando alerts.log directo en el manager cuando una prueba con solo 2 intentos no generó la alerta esperada — no era un bug, era el umbral funcionando como debía).

Otras reglas que entran en juego según el escenario: 5557 (unix_chkpwd failed), 5501/5503 (eventos PAM de login), 5715 (sshd auth success — importante para detectar el patrón "muchos fallos + un éxito", la firma clásica de una fuerza bruta exitosa).

Y un detalle que me pareció importante mostrar en la demo: incluso si el atacante corta la conexión a mitad de camino, queda registrado. Nada pasa desapercibido si el sistema está mirando.

La demo

Con todo enrolado y las reglas activas, simulé un ataque de fuerza bruta por SSH contra el "servidor" monitoreado. En el Wazuh Dashboard, en tiempo real:

Aparecen los intentos fallidos individuales (regla 5760) uno por uno
Al tercer intento consecutivo, dispara la alerta de nivel 10 (regla 2502)
Queda todo el registro navegable — origen, timestamp, usuario probado

Por qué esto importa para una mipyme

Ninguna de estas herramientas cuesta un dólar en licencias. Lo que cuesta es el tiempo de armarlo bien — y ese es exactamente el punto: una mipyme que recién está construyendo su infraestructura puede tener visibilidad real de sus propios logs sin presupuesto corporativo ni un equipo de seguridad dedicado.**

No hace falta ser una empresa con SOC 24/7 para dejar de operar a ciegas. Hace falta, como mínimo, saber que el registro existe y que alguien (o algo) lo está mirando.

Qué sigue

El próximo paso en este mismo lab es sumar respuesta activa — que el propio sistema bloquee automáticamente al atacante cuando se dispara la alerta de fuerza bruta, sin que nadie tenga que estar mirando la pantalla en el momento exacto. Ese va a ser el tema del próximo artículo/video.

¿Tu empresa, por más chica que sea, tiene visibilidad de sus propios logs? Te leo en los comentarios.

Trabajo en infraestructura TI en Paraguay/Argentina — si te interesa este tipo de contenido (ciberseguridad, networking, infraestructura, todo con foco práctico), conectemos en LinkedIn: Santiago Ruiz Díaz

DEV Community: Santiago Ruiz Diaz