El Rincon de Jose

En la anterior guía vimos como instalar el cortafuegos.

En esta veremos con instalar Wazuh desde los repositorios APT.

Si bien Wazuh con docker me dio innumerables quebraderos de cabeza. La experiencia va siendo un grado y no entrar en bucle con las IAs es fundamental.

Gemini me dio la teoría correcta de como configurar el lanzador. Pero se le “atraganto” las modificaciones con el código. Sus diff.

¡¡¡OJO!!! Lanzar el script tal y como os lo da Lovabale. Tiempo hay luego para rectificar y vereis porque.

Menos mal que me di cuenta a tiempo.

Le paso la pregunta a Gemini.

Jose

Ayer instalamos el cortafuegos sin ningún contratiempo. Hoy ¿podremos lanzar Wazuh?. Esto es lo que tengo en el lanzador.

Gemini

¡Buenos días! Me alegra mucho saber que el búnker ya tiene sus muros (el cortafuegos) bien levantados. Hoy vamos a por el "cerebro" del Servidor 1: Wazuh SIEM.

Respondiendo a tus dudas para que hoy también des en el blanco:

1. ¿Qué parámetros debes cambiar en el formulario?

Mirando lo que tienes, los valores por defecto son excelentes para una instalación estándar. Aquí te detallo el porqué:

installDir (/opt/soc-stack): Es la ruta ideal. A diferencia del cortafuegos (que va a /etc), Wazuh es una suite grande y es mejor que viva en /opt. Déjalo así.

serverIp (auto): Manténlo en auto. El script detectará tu IP (192.168.1.100) por sí solo, lo cual es más limpio.

clusterName (wazuh-soc): Es solo un nombre cosmético para el cluster, ese está perfecto.

Puertos (1514, 1515, 55000, 443): ¡No los toques! Son exactamente los mismos que abrimos ayer en el cortafuegos. El script de hoy los usará para configurar los servicios internos y que todo encaje como un puzzle.

indexerPassword: Se genera aleatoriamente. Anota esta contraseña cuando se genere el script (o el script te la mostrará al final), ya que es la "llave maestra" para la base de datos de logs.

2. ¿Desde dónde lanzar el script?

Sí, puedes lanzarlo desde /home/jose sin problemas.

Ayer vimos que tu carpeta personal tiene los permisos correctos (drwxr-x---), así que el flujo sería:

Sube el archivo install-wazuh.sh a /home/jose.

Dale permisos: sudo chmod +x install-wazuh.sh.

Ejecútalo: sudo bash install-wazuh.sh.

El script se encargará de crear la carpeta /opt/soc-stack, descargar los paquetes y configurar todo.

3. Sobre el cortafuegos y el arranque

Efectivamente, el cortafuegos ya está activo. UFW y Fail2ban se configuran como servicios del sistema, por lo que arrancan automáticamente al encender el servidor. No tienes que hacer nada extra para que sigan protegiéndote.

Un último consejo:

Wazuh es un software potente. Asegúrate de que tu Servidor 1 tenga al menos 8 GB de RAM y 4 núcleos de CPU (como dice el requisito mínimo). Si el servidor es muy pequeño, la instalación de la base de datos (Indexer) podría ir lenta o fallar.

¡Todo listo! Genera el script, súbelo a tu home y prepárate para ver nacer tu SIEM. ¡Aquí estaré si te salta cualquier aviso!

Fin de Gemini
Gemini ademas me da una serie de diff que acepto y en mala hora, salvo los cambios.

Cambios que afectan a las rutas y los permisos.

Como no se que cambios os puede dar a vosotros no los documentare.

Veréis que a las primera de cambio cambie la estrategia. Lo fundamental es que el código original ya ha sido modificado.

Ya vimos como descargar el archivo install-firewall.sh del lanzador.

Hacemos lo mismo con Wazuh. Seleccionamos

Nos vamos a Generar Script (sh.)

Le doy a Guardar y lo alojara por defecto en Descargas.

He creado una carpeta al uso para esta serie de archivos y lo llevo ahí.

Voy a WinSCP y lo paso al servidor en la carpeta home/jose

En Ubuntu lo lanzo. Le damos los perminsos.

sudo chmod +x install-wazuh.sh

Y lo ejecutamos con:

sudo bash install-wazuh.sh

sudo ./install-wazuh.sh

***Importante***

Si tenemos problemas y tenemos que desinstalar para volver a lanzar el script, ejecutamos:

1. Limpieza total (no necesitas reinstalar Ubuntu)

sudo bash install-wazuh.sh --uninstall

Vemos el primer error.

Voy a documentar ese error y espero que sea el ultimo.

Le paso el código a Gemini y haber que me dice.

Esta va a ser la única conversacion con Gemini sobre errores que voy a documentar.

El motivo es que ya estan documentadas varias conversaciones sobre errores en la instalación de Wazuh en el anterior SOC.

Por lo que si no hay nada relevante, las preguntas estándar son las mismas y las preguntas puntuales serán las que nos de a cada uno la instalación.

Gemini

¡Vaya! Nadie dijo que el camino a la cima del SOC fuera una línea recta, pero no te preocupes, que este tropiezo es el más común de todos cuando instalamos Wazuh Indexer (que es el motor de búsqueda y base de datos).

El error indica que el servicio ha intentado arrancar y ha fallado casi al instante. Hay un 90% de probabilidades de que sea por una de estas tres razones técnicas. Vamos a investigar:

Paso 1: Ver el "grito" de error

Para saber exactamente por qué se queja, ejecuta este comando y busca las líneas rojas al final:

sudo journalctl -u wazuh-indexer --no-pager | tail -n 50

Esta salida de la pasare a Gemini cuando tenga toda la información que me ha pedido.

Paso 2: Los sospechosos habituales (Revisión rápida)

Lo más probable es que sea uno de estos dos problemas:

A. El límite de memoria virtual (vm.max_map_count)

Wazuh Indexer (basado en OpenSearch) necesita que el sistema le permita mapear muchas áreas de memoria. Si el valor es bajo, el servicio "se suicida" al arrancar.

Comprueba el valor actual:

cat /proc/sys/vm/max_map_count

Si el número es menor a 262144, ahí tienes al culpable. Aplica el parche manualmente así:

sudo sysctl -w vm.max_map_count=262144

(Nota: El script suele intentar hacerlo, pero a veces el kernel de la VM no lo acepta de primeras).

B. Memoria RAM insuficiente

El Indexer es muy hambriento. Si tu servidor tiene menos de 4GB o 8GB de RAM, es posible que el proceso Java (JVM) no encuentre sitio para sentarse.

Comprueba tu RAM libre:

free -h

Si ves que te queda muy poca (menos de 1GB libre), es posible que tengamos que ajustar la "heap memory" del Indexer para que no pida tanto.

C. Certificados

Si es una instalación desde cero, a veces los certificados SSL no se generan bien o no tienen los permisos correctos en /etc/wazuh-indexer/certs.

¿Qué te sugiero hacer ahora mismo?

Ejecuta el comando del Paso 1 (journalctl) y dime qué pone. Si ves algo como "Initial heap size ... larger than the total amount of physical memory" o "max virtual memory areas vm.max_map_count [65530] is too low", ya sabemos qué es.

Dime cuánta RAM tiene asignada esa máquina virtual.

No desesperes. El Indexer es la pieza más pesada de mover; una vez que esta arranque, el resto de Wazuh (Manager y Dashboard) van sobre ruedas.

¡Espero tus logs para darte la solución exacta!

Fin de Gemini

Me manda ejecutar:

sudo ls -lh /etc/wazuh-indexer/certs/

Y la salida es:

ls: cannot access '/etc/wazuh-indexer/certs/': No such file or directory

# Cambiar el dueño de toda la carpeta de configuración al usuario wazuh-indexer

sudo chown -R wazuh-indexer:wazuh-indexer /etc/wazuh-indexer

# Dar permisos de lectura/ejecución al usuario en la carpeta de certificados

sudo chmod -R 700 /etc/wazuh-indexer/certs

# Dar permisos de lectura a los archivos dentro (600: solo el dueño lee y escribe)

sudo chmod 600 /etc/wazuh-indexer/certs/*

Ejecuto lo que me da.

Los certificados y los permisos en Wazuh son un autentico dolor de muelas.

Es mas, Gemini se lía con la consola de VSCode y la de Ubuntu y me da los comandos de una para la otra. Es decir me aconseja ejecutar

node -v

para ver si ya tengo instalado la versión 20 o 22 en la Shell de Ubuntu cuando corresponde a la consola de VSCode.

Por supuesto que en Ubuntu me va a dar que no esta y ni se le espera. Aqui es cuando me doy cuenta que Gemini me esta llevando por el mismo camino que en la instalación de Wazuh en el anterior SOC.

Si ese mismo comando lo ejecuto en VSCode.

Vemos que la versión de Node es la 24.14.0

Volvemos al problema de las versiones y de en que fecha termino el entrenamiento esta IA.

Recordamos que la misma IA me dijo que su entrenamiento termino en 2024

Me sigue dando comandos aleatorios para las dos terminales y tiro por el camino del medio.

Cuando veamos una incongruencia tan flagrante como esa. Tenemos dos caminos:

Reformular la pregunta.

Cambiar de IA y ver las diferencias.

Mi error ha sido aceptar los cambios mediante los diff que me dio Gemini.

Y como ya dije anteriormente Lovable nos da poco margen de maniobra, pero si sabemos aprovechar la pregunta., la respuesta suele se valida.

Con los 5 créditos diarios nos facilita un par de peguntas.

A Lovable le paso la primera salida que le mostré a Gemini. Le pido por si acaso que me restablezca el código original. (Fundamental)

Los cambios que me dio Gemini son revertidos

Los cambios en Lovable se los tenemos que pasar a VSCode desde Git Hub y lo hacemos desde la consola de VSCode con:

git pull origin main

O si bien queremos que nos descargue solo los archivos modificados, en este caso generators/wazuh.ts y generators/wazuh.ts

git restore src/lib/generators/wazuh.ts
git restore src/lib/store.ts
git pull origin main

Esta es la salida que me da Lovable para los cambios en Git Hub.

Como se que archivos han sido modificados he aplicado los anteriores comandos.

Le pregunto a lovable. ¡¡¡Esto nos tiene que quedar muy claro!!!. Me da estas alternativas.

Jose

Ahora entiendo que para que VSCode me de lo que tenemos aquí (en Lovable) es bajarlo de Git Hub con.…

git restore src/lib/generators/wazuh.ts

git restore src/lib/store.ts

git pull origin main

Lovable

Pero ojo con el matiz: `git restore` descarta tus cambios locales de ese fichero (los pierdes). Solo hazlo si esos cambios locales no te interesan.

Opción A — descartar lo local y traer lo de GitHub (lo que propones):

git restore src/lib/generators/wazuh.ts
git restore src/lib/store.ts
git pull origin main

```

Opción B — guardar lo local por si acaso, y luego traer:

git stash
git pull origin main
git stash pop # si quieres recuperar tus cambios encima

```

Opción C — ver primero qué cambios locales tienes antes de decidir:

git status
git diff src/lib/generators/wazuh.ts

```

En tu caso, como los cambios "buenos" (sanitize_password + versión 4.14.5) ya están en GitHub gracias a Lovable, Opción A es la correcta y no pierdes nada útil. Después en el servidor:

sudo bash install-wazuh.sh --uninstall && sudo reboot

# y al volver:

sudo bash install-wazuh.sh

```

Restablecer a GitHub

Ver cambios antes

Despliegue en un clic

Validar contraseña si la pìde.

Fin de Lovable.

Daros cuenta que tambien Lovable me dice que la version que me da es la 4.14.5. Pues no señor. Luego lo veremos.

En la imagen vemos como realice los cambios en VSCode para que los bajara de Git Hub y por ende de Lovable.

Ya tendríamos los cambios en VSCode

Es fundamental para que esos cambios vayan al lanzador

Desinstalamos Wazuh en Ubuntu

sudo bash install-wazuh.sh --uninstall && sudo reboot

Con esto tengo desinstalado Wazuh. No tenemos porque volver a instalar Ubuntu.

Ya hemos visto como volver a lanzarlo.

Genero de nuevo el script en el lanzador.

Lo paso a Ubuntu con WinSCP.

Le doy permisos.

Lo ejecuto.

La instalación se realiza en teoría correctamente

Pero nos ha dado la version 4.9.2.

la misma version que nos daba Gemini en el anterior SOC.

Es la batalla de las versiones.

Yo quiero la ultima version. La 4.14.5

Por lo que se lo voy a pedir de nuevo a Lovable.

Esta es la pregunta exacta que le formule.

Jose

Buenos días Genio/a...El script funciona...Nos da la contraseña del lanzador.... INSTALACIÓN COMPLETADA

============================================================

Wazuh Dashboard: https://192.168.1.100:443

Wazuh API: https://192.168.1.100:55000

Manager (agent): 192.168.1.100:1514

Enrolamiento: 192.168.1.100:1515

Usuario: admin

Password: WazuhSecurePass*123 (o el generado en /root/wazuh-passwords.txt)

Cluster: wazuh-soc

Versión: 4.9.2

============================================================

jose@soc-server-1:~$

Pero...¿Me estas dando la version de Wazuh 4.9.2 ¿Es posible que descargues e instales la ultima version 4.14.5? Ya se que alguna IA no tiene entrenamiento mas allá del año 2024 ¿Pero tú?...¿Es posible que ese script se adapte a la version 4.15.5? Cuando me diste el SOC con wazuh con docker ya me diste la ultima version.

Lovable

Cambios:

- Versión por defecto Wazuh: `4.9.2` → `4.14.5` (la última estable a día de hoy, 9 de mayo de 2026).

- Migración automática: si tenías `4.9.2` guardado en el configurador, salta a `4.14.5` al recargar.

El script ya estaba preparado para cualquier versión — usa la rama mayor.menor automáticamente:

```bash

BRANCH=$(echo "$WAZUH_VERSION" | awk -F. '{print $1"."$2}')

curl -sO "https://packages.wazuh.com/${BRANCH}/wazuh-install.sh"

```

Con `4.14.5` descargará desde `https://packages.wazuh.com/4.14/wazuh-install.sh` (el assistant oficial de la rama 4.14).

Pasos:

1. Recarga el configurador (verás `4.14.5` en el campo de versión Wazuh — si quieres otra, edítalo libremente, ej. `4.15.0` cuando salga).

2. Regenera el script y súbelo al servidor.

3. `sudo bash install-wazuh.sh --uninstall && sudo reboot`

4. `sudo bash install-wazuh.sh`

Nota: cuando Wazuh saque 4.15.x bastará con cambiar el campo "Versión" en el configurador, no hace falta tocar el script. Cuéntame cómo va el dashboard 🛡️

Fin de Lovable.

Vuelvo a pasar a VSCode los cambios de Lovable.

Los cambios que se realizan en Lovable van a Git Hub. Pero no a VSCode directamente, por lo que los descargamos como vimos anteriormente.

Y los cambios que se realizan en VSCode no pasan directamente a Lovable hay que subirlos a Git Hub mediante los commits.

Tened en cuenta esto.

Descargo el script de nuevo desde el lanzador...Luego haré los cambios en VSCode si procede para pasárselos a Git Hub.

Se lo paso a Ubuntu.

Le doy permisos y lo ejecuto

sudo bash install-wazuh.sh

Y ¡¡¡Bingo!!!

Ya esta en la ultima version.

Nos vamos al navegador.

Avanzado.

Acceder.

Nos logueamos con el usuario admin y con la contraseña que nos dará la instalación. En mi caso.

WazuhSecurePass*123

Ya estamos en el panel.

Si vamos a comprobar de nuevo la versión.

Vemos que efectivamente estamos con la ultima version.

Con esto ya tendríamos Wazuh instalado.

La configuración ya la veremos en su momento.

Cada ejercicio me da un plus de experiencia. Espero que a vosotros os pase lo mismo.

Si me dejo llevar por Gemini como en la instalación de Wazuh en el anterior SOC, todavía estaría “mareando la perdiz” y perdido en cambios y mas cambios.

Aprovechad siempre que podáis la IA Lovable. Al fin y al cabo es la madre del SOC automatizado,

Barakaldo 16de mayo de 2026