DEV Community: Santiago Ruiz Diaz

Ataqué mi propio servidor con Kali Linux — así lo agarró Wazuh, paso a paso

Santiago Ruiz Diaz — Fri, 11 Sep 2026 03:33:27 +0000

De qué se trata esto

Este es el segundo video del bloque de ciberseguridad. En el primero armé un SIEM gratis con Wazuh y Kibana. Acá le doy la vuelta: simulo un ataque completo contra mi propio lab, con las mismas herramientas que usa un atacante real, y muestro exactamente qué queda invisible y qué queda registrado del otro lado.

Nada de esto corre contra infraestructura de terceros — todo el lab vive en una red virtual aislada (Host-only de VMware, 192.168.220.0/24), sin salida a mi red real ni a internet.

El lab

Dos objetivos, dos propósitos distintos:

Metasploitable2 (una VM deliberadamente vulnerable, hecha para practicar) — solo para mostrar exposición real. No tiene el agente de Wazuh instalado (corre sobre Ubuntu 8.04, muy por debajo del piso mínimo que soporta Wazuh — Debian 10+).
Un contenedor con el agente de Wazuh activo (SSH en el puerto 2222, Apache en el 8080), enrolado contra el mismo manager del video anterior. Este es el que "ve" todo.

El stack de Wazuh en sí (dashboard, indexer, API) quedó atado únicamente a 127.0.0.1 en el host — ni Kali ni mi red real lo pueden alcanzar. Sin este detalle, cualquier escaneo contra mi propia máquina terminaría revelando el propio SIEM en los resultados, lo cual además de ser un problema de seguridad real, rompe la demostración.

Fase 1 — Descubrimiento (no sabía nada todavía)

nmap -sn 192.168.220.0/24

-sn le dice a nmap "no toques puertos, solo decime quién está vivo". Es el primer paso de cualquier reconocimiento: antes de elegir un objetivo, hay que saber qué hay en la red. Encontré 4 hosts — descartando mi propia Kali y el servidor DHCP de la red virtual, quedaron 2 candidatos reales.

Fase 2 — Enumeración (¿qué corre en cada uno?)

nmap -sV <IP>

Sobre Metasploitable2, esto tiró 24 puertos abiertos — un inventario de dos décadas de software sin actualizar: vsftpd 2.3.4 (versión con una puerta trasera pública conocida), telnet sin cifrar, y un puerto literalmente identificado como Metasploitable root shell. Es la foto perfecta de "así se ve un sistema que nunca se tocó".

Sobre el segundo objetivo, apareció SSH (2222) y HTTP (8080) — bastante más acotado. Ahí es donde decidí atacar en serio.

Fase 3 — Ataque dirigido

Credenciales, sin trucos

La tentación fácil acá era armar una lista de contraseñas a mano con la respuesta ya adentro. Preferí hacerlo honesto: usé rockyou.txt, la base de contraseñas filtradas en una brecha real de 2009 que Kali trae preinstalada, y que sigue siendo el estándar de facto para ataques de diccionario.

gunzip -k /usr/share/wordlists/rockyou.txt.gz
head -20 /usr/share/wordlists/rockyou.txt > passwords.txt

Configuré el objetivo con una contraseña genuinamente débil (123456 — la #1 más común del mundo según esa misma base) y dejé que Hydra la encontrara sola, sin ayuda:

hydra -l root -P passwords.txt ssh://192.168.220.1:2222

La encontró en 5 segundos, contra apenas 20 intentos.

Reconocimiento web

nikto -h http://192.168.220.1:8080

8283 pedidos automáticos contra el Apache del objetivo. Encontró indexado de directorio abierto, el método HTTP TRACE activo (vulnerable a Cross-Site Tracing), headers de seguridad faltantes, y hasta probó patrones de Shellshock — una vulnerabilidad de 2014 que muchos sistemas viejos todavía no tienen parchada.

Fase 4 — Lo que Wazuh vio (y lo que no vio)

Acá está el punto central del video. El reconocimiento (Fases 1 y 2) no generó ni una sola alerta. nmap, por diseño, no intenta autenticarse contra nada — solo identifica qué hay. Es completamente invisible para un sistema de logging basado en intentos de autenticación.

Recién en la Fase 3, cuando hubo conexiones reales con intentos de login y pedidos HTTP activos, empezó a aparecer todo:

Del lado SSH, la regla que se disparó no fue la que yo esperaba en un principio (había memoria de una regla 2502 simple) — resultó ser la 40112, nivel 12: "Multiple authentication failures followed by a success". Nombre perfecto: describe exactamente el patrón de un ataque de fuerza bruta que terminó funcionando.

Del lado web, el escaneo de Nikto disparó una batería completa de detecciones distintas:

Regla	Qué detectó	Cantidad
31153 (nivel 10)	Múltiples ataques web comunes, mismo origen	29
31154 (nivel 10)	Múltiples intentos de XSS, mismo origen	27
31151 (nivel 10)	Múltiples errores 400, mismo origen	537
31103	Intento de SQL injection	5
31105	Intento de XSS	246
31166	Intento de Shellshock	61
30306	Acceso a directorio prohibido	109

Un solo escaneo automatizado, en unos pocos minutos, generó miles de eventos correlacionados sin que yo tuviera que estar mirando la pantalla del lado defensivo.

El dato que más vale la pena llevarse

La contraseña que rompió el servidor fue 123456. No hizo falta una técnica sofisticada — hizo falta, literalmente, una lista con las 20 contraseñas más comunes del mundo. La diferencia entre "vulnerable en 5 segundos" y "prácticamente imposible" para este vector específico es una contraseña larga y única. Nada más.

Y la diferencia entre "esto pasó y nadie se enteró" y "esto quedó registrado con usuario, IP, y timestamp exacto" no fue tecnología cara — fue tener algo mirando los logs.

Qué sigue

Con los dos videos de este bloque (detección con Wazuh, ataque con Kali) ya está armada la base completa de ciberseguridad práctica. El próximo bloque pasa a Networking.

Video completo acá: LinkedIn

Trabajo en infraestructura TI en Paraguay/Argentina — si te interesa este tipo de contenido, conectemos en LinkedIn: Santiago Ruiz Díaz

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