La idea era simple de enunciar y mucho más interesante de resolver: quería ver qué le pasa a mis servicios en la nube. Quedate, que el camino tiene sus vueltas.

El problema que resuelve

Tenemos un servicio corriendo en un servidor en la nube. Funciona, responde, todo bien. Pero si te parás un segundo a pensarlo, en realidad no sabés casi nada de lo que le pasa cuando no lo estás mirando. ¿Alguien lo está escaneando ahora mismo buscando una puerta? ¿El certificado SSL vence la semana que viene y te vas a enterar cuando el navegador tire la alarma roja? ¿El disco se está llenando de a poco hasta que un día tumba todo? ¿Qué vulnerabilidades conocidas arrastran los paquetes que tenés instalados?

La respuesta honesta, para la mayoría de nosotros, es "ni idea". Estás volando a ciegas.

Y hay algo más: normalmente la seguridad (intrusiones, vulnerabilidades) y la salud (¿está vivo?, ¿responde rápido?) viven en mundos separados, con herramientas separadas. Yo quería juntar las dos mitades en un solo lugar, sin gastar una fortuna y —esto era importante— sin exponer nada que bajara la postura de seguridad que ya tenía. Ese era el desafío.

Wazuh - Prometheus + Grafana

Acá es donde se nota el criterio, así que me detengo un poco.

Wazuh es un amigo conocido; lo he usado en el trabajo para analizar ciertas cosas de los servicios tanto Windows y Linux a nivel omPremise. Es la primera vez que lo iba a intentar hacerlo desde Wazuh onPrem y un servicio en nube. Es aqui donde he encontrado alternativas como Tailscale en lugar de pelearme con WireGuard a mano o, peor, exponer servicios a internet. Cero exposición pública. Esto fue clave, porque no quería tocar la nota de seguridad del sitio.

Para la parte de salud podría haber tirado de Zabbix, que ya manejo, pero me decidí por el combo Prometheus + Grafana. ¿Por qué? Por el sondeo con blackbox: me deja medir el estado HTTP, la latencia y, sobre todo, cuántos días le quedan al certificado SSL antes de vencer. Y porque Grafana me permitía meter todo —métricas y seguridad— en un mismo tablero. El "panel único" que quería.

Montando el laboratorio

La arquitectura tiene una idea central que vale la pena entender: los cerebros pesados viven en el laboratorio, y en el servidor de la nube solo van piezas livianas. O sea, Wazuh, Prometheus y Grafana corren en mi homelab, y en el servidor monitoreado solo instalé un agente liviano y un exportador de métricas. Las dos puntas se hablan por el túnel privado de Tailscale.

Levantar esto tuvo sus tropiezos, y te los cuento porque son justo las cosas que ningún tutorial te avisa:

  • Fedora estrenó dnf5, y la sintaxis para agregar el repositorio de Docker cambió. El comando viejo que sale en todos lados ya no anda. Me comió un buen rato hasta darme cuenta.
  • SELinux estaba en enforcing (como debe ser) y eso significa que cada archivo de configuración que montaba en un contenedor había que etiquetarlo bien, o el contenedor no lo podía leer. La tentación de "desactivá SELinux y listo" estaba ahí... y la ignoré, que es lo correcto.
  • Wazuh no arrancaba y me volví loca un rato. El indexer necesita un parámetro del kernel más alto de lo normal; hasta que no lo subí, el contenedor reiniciaba en loop sin decirme gran cosa.

Una vez ordenados esos tres detalles, todo encajó: el agente del servidor empezó a reportar al laboratorio por el túnel, y de golpe tenía datos reales entrando.

Resultado

Resultado final del montaje del SIEM

Decisiones técnicas clave

Hay un puñado de decisiones de las que estoy contenta, porque son las que separan un "instalé una herramienta" de un "diseñé algo":

El SIEM va FUERA del servidor que monitorea. Esto no es capricho. Si el servidor se compromete, querés que los logs ya estén en otro lado, fuera del alcance del atacante. Por eso los cerebros viven en el lab y no en la nube.

Todo por el túnel privado, ni un puerto público nuevo. Esto me permitió sumar todo el monitoreo sin tocar la configuración de seguridad del sitio. El exportador de métricas, además, lo dejé escuchando solamente en la interfaz del túnel, nunca en la cara pública.

No guardar secretos dentro del propio SIEM. Esta es sutil y me gusta. Al monitorear la integridad de mis archivos, Wazuh puede guardar el "antes y después" de cada cambio. Pero si dejaba eso activo sobre la carpeta del proyecto, terminaba copiando el contenido de mi archivo de secretos dentro del SIEM. Así que lo configuré para que me avise que un archivo sensible cambió, sin copiar qué decía. Detalle chico, criterio grande.

Lecciones aprendidas

Lecciones aprendidas

Acá es donde el proyecto se puso humano, porque metí la pata varias veces.

La mejor anécdota es la de Tailscale. Autentiqué cada máquina con una cuenta distinta sin darme cuenta, así que quedaron en redes privadas separadas que no se veían entre sí. Resultado: me pasé un buen rato haciendo ping con 100% de pérdida de paquetes, convencida de que era un problema de firewall, revisando reglas que estaban perfectas. El problema era yo. Lección grabada a fuego: misma identidad en todos los nodos.

La segunda gran lección fue sobre el triaje. El primer escaneo de hardening CIS me dio un 51,9%. Ver 114 controles en rojo fue algo preocupante aunque, luego de leerlos de verdad, 23 eran de tener particiones separadas, algo que en un servidor en la nube no podés hacer sin reconstruir la máquina entera. Y un montón de los de firewall se contradicen entre sí por diseño, porque el benchmark testea tres caminos alternativos y vos implementás uno solo. Ahí cayó la ficha más importante de todo el proyecto: la madurez no es llegar al 100%, es saber qué arreglar, qué aceptar y qué ya tenés cubierto por otro control. Apuntar a 100% en un checklist es de principiante; razonar el riesgo es de profesional.

Un bonus de esa misma categoría: perdí un rato buscando cómo habilitar una herramienta (CIS-CAT) que en realidad es paga, cuando el módulo gratuito de Wazuh ya había hecho exactamente ese trabajo. A veces la solución ya estaba corriendo y yo mirando para otro lado.

¿Qué haría distinto? Dos cosas. Primero, dejar la cuenta del túnel clarísima desde el minuto cero (ya sabés por qué). Y segundo —esto es para tu yo del futuro si hacés algo parecido— documentá el "antes" antes de tocar nada. Casi me quedo sin la captura del score inicial, y ese "antes y después" es la mejor evidencia de que tu trabajo sirvió.

Conclusión

Pasé de no saber prácticamente nada de mis servicios, a tener un panel donde veo, juntas y en vivo, las vulnerabilidades y la salud. El score de hardening subió de manera bien visible, el SIEM detecta intentos de escaneo contra el sitio, el monitoreo de integridad me avisa si alguien toca un archivo importante, y sé exactamente cuántos días le quedan al certificado antes de vencer.

Pero si tengo que quedarme con una sola cosa, no son las herramientas: es el mindset. Pensar en riesgo en vez de en checklists. Usar controles compensatorios cuando el control "ideal" no aplica. Y, sobre todo, lo poderoso que es un laboratorio casero para aprender de verdad, equivocándote tranquila, sin romper nada en producción.

Obs: las direcciones IP fueron ocultadas a propósito