Homelab SOC #09 - Incorporando Ubuntu Server al SOC mediante SSH Pivoting
En el capítulo anterior incorporamos nuestro primer endpoint Windows al laboratorio y comenzamos a recibir eventos desde un equipo cliente.
Sin embargo, un entorno empresarial rara vez está compuesto únicamente por estaciones de trabajo. Gran parte de los servicios críticos se ejecutan sobre servidores Linux, por lo que resulta indispensable que nuestro SOC también sea capaz de monitorizarlos.
En este capítulo incorporaremos Ubuntu Server como un nuevo agente de Wazuh.
Además, aprovecharemos una situación muy habitual en redes corporativas: el servidor Ubuntu se encuentra en una red interna y no es accesible directamente desde el equipo host. Para administrarlo utilizaremos un salto SSH a través del servidor Debian, reproduciendo el funcionamiento de un Jump Server o Bastion Host.
Objetivo de este capítulo
La pregunta que responderemos será:
¿Cómo instalar un agente de Wazuh en un servidor Linux ubicado en una red interna sin acceso directo?
Al finalizar este capítulo tendremos:
- Ubuntu Server registrado en Wazuh.
- Comunicación cifrada con el servidor.
- Administración remota mediante SSH.
- Un nuevo endpoint Linux enviando eventos al SIEM.
Arquitectura del laboratorio
Después de este capítulo, la infraestructura del laboratorio quedará de la siguiente forma:
HOMELAB SOC
Arch Linux (Host)
192.168.100.100
│
SSH (22)
│
┌───────────▼────────────┐
│ Debian Server │
│ Wazuh Manager │
│ Bastion Host │
│ │
│ eth0 192.168.100.110 │
│ eth1 10.0.100.10 │
└───────────┬────────────┘
│
SSH (22)
│
┌───────────▼────────────┐
│ Ubuntu Server │
│ Wazuh Agent │
│ 10.0.100.30 │
└────────────────────────┘
Aunque este laboratorio está construido con máquinas virtuales, la arquitectura replica un escenario muy común en organizaciones donde únicamente algunos servidores son accesibles desde la red de administración.
Los equipos internos permanecen aislados y solo pueden administrarse a través de un servidor intermedio.
Un escenario muy común
Desde mi equipo físico puedo conectarme sin inconvenientes al servidor Debian utilizando SSH.
Sin embargo, Ubuntu Server únicamente existe dentro de la red interna del laboratorio, por lo que no dispone de conectividad directa con el host.
La situación puede representarse de la siguiente manera:
Host
│
├── Debian Server ✅ Accesible
│
└── Ubuntu Server ❌ Sin acceso directo
Afortunadamente, Debian sí posee conectividad hacia Ubuntu gracias a su segunda interfaz de red.
En lugar de modificar la topología del laboratorio o exponer innecesariamente el servidor Ubuntu, utilizaremos un salto SSH para administrarlo.
Esta técnica recibe distintos nombres dependiendo del contexto:
- Bastion Host
- Jump Server
- SSH Jump
- SSH Pivoting
Aunque el término Pivoting suele asociarse al movimiento lateral durante un ataque, en este laboratorio lo utilizaremos únicamente como una técnica de administración legítima para acceder a un servidor ubicado en una red privada.
¿Qué es un Bastion Host?
¿Por qué utilizar un Bastion Host?
Un Bastion Host, también conocido como Jump Server, es un servidor diseñado para actuar como punto de entrada hacia una red privada.
En lugar de permitir conexiones SSH directas a todos los servidores, únicamente el Bastion Host queda expuesto a la red de administración.
Entre sus principales ventajas encontramos:
- Reducir la superficie de ataque.
- Centralizar los accesos administrativos.
- Facilitar la auditoría de conexiones.
- Evitar exponer servidores internos.
- Aplicar controles adicionales como MFA o registros de sesión.
Aunque en un laboratorio podría parecer un paso adicional, en infraestructuras empresariales es una práctica ampliamente utilizada.
Accediendo mediante SSH Pivoting
El primer paso consiste en conectarnos al servidor Debian desde nuestro equipo host.
ssh usuario@192.168.100.110
Una vez dentro del servidor Debian realizamos un segundo salto SSH hacia Ubuntu Server.
ssh usuario@10.0.100.30
El recorrido realizado por la conexión puede representarse de la siguiente forma:
[ Arch Linux Host ]
│
│ SSH
▼
[ Debian Server ]
│
│ SSH
▼
[ Ubuntu Server ]
Gracias a este salto SSH fue posible copiar y ejecutar directamente los comandos generados por el Dashboard de Wazuh sin necesidad de modificar la configuración de red del laboratorio.
Desplegando el agente
Desde el Dashboard de Wazuh accedemos a:
Menu
→ Agents
→ Deploy new agent
Seleccionamos los siguientes parámetros:
- Sistema operativo: Linux (DEB amd64)
- Dirección IP del servidor Wazuh:
10.0.100.10
- Nombre del agente:
UbuntuServer
- Grupo:
Default
El asistente de despliegue genera automáticamente todos los comandos necesarios para instalar el agente.
Esto evita errores durante la configuración y simplifica enormemente el proceso de incorporación de nuevos equipos al laboratorio.
El comando generado por Wazuh ya incluye la dirección del servidor, el nombre del agente y el grupo al que pertenecerá, por lo que únicamente debemos ejecutarlo desde el equipo que deseamos registrar.
Instalando el agente
Una vez conectados al servidor Ubuntu mediante SSH, ejecutamos el comando generado por Wazuh.
wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.14.6-1_amd64.deb && \
sudo WAZUH_MANAGER="10.0.100.10" WAZUH_AGENT_NAME="UbuntuServer" \
dpkg -i ./wazuh-agent_4.14.6-1_amd64.deb
Una vez completada la instalación iniciamos el servicio.
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent
Podemos comprobar que el servicio se encuentra funcionando correctamente ejecutando:
sudo systemctl status wazuh-agent
La salida esperada será similar a:
● wazuh-agent.service - Wazuh agent
Loaded: loaded (/lib/systemd/system/wazuh-agent.service)
Active: active (running)
Una vez iniciado el servicio, el agente establece una comunicación cifrada con el servidor Wazuh utilizando los puertos 1514 y 1515.
A partir de ese momento comienza el proceso de registro y el envío periódico de eventos hacia el Wazuh Manager.
Verificando el registro desde el servidor
Ahora regresamos al servidor Debian para comprobar que el nuevo agente ha sido registrado correctamente.
sudo /var/ossec/bin/agent_control -l
Obtendremos una salida similar a la siguiente:
Wazuh agent_control. List of available agents:
ID: 000,
Name: soc-server (server),
IP: 127.0.0.1,
Active/Local
ID: 001,
Name: Windows11,
IP: any,
Disconnected
ID: 002,
Name: UbuntuServer,
IP: any,
Active
Esto confirma que el servidor Ubuntu ya forma parte de la infraestructura monitorizada por nuestro SOC.
El agente fue registrado correctamente y ya puede intercambiar información con el servidor Wazuh. A partir de este momento Ubuntu comenzará a enviar eventos de forma continua para su análisis.
Verificando desde el Dashboard
Regresando al Dashboard de Wazuh podremos acceder a:
Menu
→ Agents
Allí aparecerá el nuevo servidor registrado.
Su estado deberá mostrarse como:
Active
Además podremos consultar información como:
- Sistema operativo.
- Dirección IP.
- Versión del agente.
- Grupo asignado.
- Última conexión.
- Estado del servicio.
A medida que el servidor genere actividad, el Dashboard comenzará a mostrar nuevos eventos provenientes del agente Linux.
¿Qué información recopila el agente?
Al igual que ocurre con Windows, el agente de Wazuh recopila diferentes tipos de información del sistema operativo.
Entre ellos destacan:
- Eventos del sistema.
- Autenticaciones.
- Usuarios y grupos.
- Integridad de archivos (FIM).
- Inventario de software.
- Procesos en ejecución.
- Servicios.
- Configuración del sistema.
- Estado general del servidor.
Toda esta información viaja cifrada hasta el Wazuh Manager, donde posteriormente será analizada y correlacionada con el resto de los eventos del laboratorio.
Estado actual del laboratorio
Después de este capítulo nuestro laboratorio ya dispone de:
- ✓ Servidor Wazuh completamente operativo.
- ✓ Windows 11 registrado y monitorizado.
- ✓ Ubuntu Server registrado y monitorizado.
- ✓ Comunicación cifrada entre todos los agentes y el Manager.
- ✓ Administración mediante un Bastion Host.
- ✓ Dos sistemas operativos diferentes enviando eventos al SIEM.
La infraestructura comienza a parecerse cada vez más a un entorno empresarial real, donde distintos sistemas operativos conviven y generan telemetría que posteriormente será analizada por el SOC.
¿Qué sigue?
Hasta ahora, nuestro laboratorio es capaz de centralizar y recopilar eventos generados a nivel de sistema operativo en Windows y Linux.
Sin embargo, para obtener una visibilidad y control integrales, necesitamos dar el salto hacia la infraestructura de red. El siguiente paso estratégico será incorporar OPNsense y Suricata, una combinación robusta que nos proporcionará tanto defensa perimetral como análisis profundo de tráfico:
OPNsense (Firewall): Actuará como el núcleo táctico de la red, encargándose de la segmentación de zonas, el control de acceso estricto mediante políticas de filtrado y la auditoría de conexiones entrantes y salientes.
Suricata (IDS/IPS): Funcionará como nuestro ojo clínico en la red, realizando una inspección profunda de paquetes en tiempo real para detectar amenazas específicas como escaneos de puertos, intentos de explotación de vulnerabilidades y firmas de malware.
Al integrar ambas herramientas, nuestro laboratorio no solo observará el comportamiento aislado de los hosts, sino que blindará el perímetro y auditará todo lo que viaja por el cable. Una evolución clave que replica con precisión la arquitectura de defensa en profundidad de un SOC moderno.
Lo aprendido
En este capítulo no solo incorporamos un nuevo servidor Linux al laboratorio, sino que también reproducimos una situación muy habitual en infraestructuras empresariales: la administración de equipos ubicados en redes privadas mediante un Jump Server o Bastion Host.
Lejos de exponer directamente el servidor Ubuntu, aprovechamos la conectividad del servidor Debian para acceder mediante un salto SSH, manteniendo aislada la red interna y reduciendo la superficie de exposición.
Una vez instalado el agente de Wazuh, Ubuntu comenzó a enviar telemetría al SIEM, ampliando la visibilidad del laboratorio y permitiendo monitorizar tanto sistemas Windows como Linux desde una única plataforma.
Con cada nuevo componente, el Homelab SOC continúa evolucionando hacia un entorno cada vez más completo y cercano a la arquitectura utilizada en centros de operaciones de seguridad reales.