Homelab SOC #02 - Arquitectura del laboratorio
En la publicación anterior expliqué por qué decidí comenzar este proyecto y cuál era el objetivo de construir un laboratorio orientado a un Security Operations Center.
Sin embargo, antes de crear la primera máquina virtual o instalar la primera herramienta, necesitaba responder una pregunta mucho más importante.
¿Cómo debería estar organizado el laboratorio?
Podría comenzar instalando sistemas operativos e ir resolviendo los problemas sobre la marcha.
Probablemente funcionaría.
Pero también terminaría con un laboratorio difícil de mantener, complicado de ampliar y donde cada nueva herramienta dependería de decisiones improvisadas.
Por eso decidí detenerme un momento antes de comenzar.
Quería diseñar una arquitectura sencilla, fácil de entender y, sobre todo, que pudiera crecer conforme avance mi aprendizaje.
Después de todo, un SOC no es únicamente un conjunto de aplicaciones instaladas sobre un servidor.
Es un ecosistema donde cada componente cumple una función específica.
Y esa será precisamente la filosofía de este laboratorio.
Objetivos del diseño
Antes de pensar en tecnologías concretas definí algunos principios que quiero mantener durante toda la serie.
La arquitectura debía cumplir varios objetivos.
- Ser sencilla de replicar.
- Utilizar herramientas Open Source siempre que sea posible.
- Aprovechar el hardware disponible.
- Simular un pequeño entorno empresarial.
- Poder crecer sin necesidad de reconstruir todo desde cero.
- Documentar cada decisión tomada durante el proceso.
No pretendo construir un laboratorio gigantesco desde el primer día.
Prefiero comenzar con una base sólida e ir incorporando nuevas piezas conforme cada capítulo lo requiera.
Uno de los principales objetivos de esta serie es demostrar que es posible construir un laboratorio muy completo utilizando un equipo doméstico, siempre que exista una buena planificación.
¿Por qué varias máquinas virtuales?
Una de las primeras decisiones fue evitar instalar todas las herramientas en un único sistema operativo.
Aunque hacerlo simplificaría la instalación inicial, también dificultaría comprender cómo interactúan realmente los distintos componentes de un SOC.
En un entorno real existen diferentes equipos generando eventos continuamente.
Servidores Linux.
Equipos Windows.
Usuarios.
Servicios.
Aplicaciones.
Dispositivos de red.
Mi intención es reproducir esa idea, aunque sea a pequeña escala.
Cada máquina virtual representará un rol diferente dentro del laboratorio.
Eso permitirá observar cómo se generan los eventos, cómo viajan hasta el servidor principal y cómo posteriormente serán analizados.
Arquitectura inicial
La primera versión del laboratorio estará formada por cinco equipos.
| Máquina | Función |
|---|---|
| Arch Linux | Equipo anfitrión (Host) |
| Debian Server | Servidor principal del SOC |
| Windows 11 | Equipo cliente Windows |
| Ubuntu Server | Segundo equipo Linux |
| Kali Linux | Simulación de ataques |
Toda la infraestructura será ejecutada desde mi estación de trabajo utilizando VirtualBox como plataforma de virtualización.
Arquitectura inicial del laboratorio
INTERNET
│
┌──────────────────┐
│ Arch Linux Host │
└────────┬─────────┘
│
VirtualBox (NAT)
│
┌──────────────┬────────┴───────────┬─────────────┐
│ │ │ │
│ Debian Server Windows 11 Ubuntu Server
│ (Servidor SOC) Cliente Cliente
│
└───────────────────────────────┐
│
Kali Linux
Máquina atacante
Esta arquitectura representa únicamente el punto de partida.
Conforme el proyecto avance irán apareciendo nuevos servicios, herramientas y componentes que enriquecerán el laboratorio.
El papel de cada máquina
Cada sistema operativo tendrá una responsabilidad claramente definida.
Arch Linux
Será el sistema operativo anfitrión.
Desde él se administrarán todas las máquinas virtuales, snapshots y configuraciones del laboratorio.
Debian Server
Comenzará siendo un servidor Linux limpio.
Más adelante se convertirá en el corazón del laboratorio, alojando las diferentes herramientas que iremos instalando durante la serie.
Windows 11
Representará un equipo de usuario dentro de la infraestructura.
Será una de las principales fuentes de eventos de seguridad y permitirá incorporar herramientas específicas del ecosistema Windows en capítulos posteriores.
Ubuntu Server
Funcionará como un segundo equipo Linux monitorizado.
Su presencia permitirá comparar el comportamiento entre diferentes sistemas operativos.
Kali Linux
Será utilizado para generar actividad ofensiva completamente controlada.
Escaneos, enumeración de servicios y simulaciones de ataque servirán para producir eventos que posteriormente podrán ser detectados e investigados desde el laboratorio.
En esta etapa todavía no instalaré herramientas como Wazuh, Sysmon o Suricata.
Cada una aparecerá en el capítulo correspondiente para comprender su funcionamiento desde cero y mantener una evolución progresiva del laboratorio.
¿Por qué VirtualBox?
Existen excelentes alternativas como Proxmox, VMware o KVM.
Sin embargo, decidí utilizar VirtualBox por dos motivos muy sencillos.
El primero es que ya forma parte de mi entorno habitual de trabajo.
El segundo, y probablemente el más importante, es que cualquier persona puede replicar este laboratorio fácilmente sin necesidad de disponer de un servidor dedicado o hardware adicional.
Mi intención es que cualquier lector pueda seguir la serie utilizando únicamente su equipo personal.
Comunicación entre los equipos
Aunque todavía no existe ningún SIEM instalado, sí resulta útil comprender cómo viajará la información dentro del laboratorio.
La idea general será la siguiente.
Flujo general de eventos
Windows / Ubuntu
│
▼
Servidor SOC
│
Analiza eventos
│
▼
Dashboard
│
▼
Analista
En los próximos capítulos iremos completando este flujo hasta convertirlo en un pequeño Centro de Operaciones de Seguridad completamente funcional.
Una arquitectura pensada para crecer
El laboratorio que comienza hoy será mucho más pequeño que el que espero tener dentro de algunos meses.
Durante las siguientes fases irán apareciendo nuevas herramientas, nuevos agentes y nuevos escenarios de ataque.
Eso significa que esta arquitectura evolucionará continuamente.
Y precisamente esa es una de las razones por las que decidí documentar todo el proceso desde el principio.
No quiero mostrar únicamente el resultado final.
Quiero mostrar cómo el laboratorio fue creciendo decisión tras decisión.
Este laboratorio no pretende replicar un Centro de Operaciones de Seguridad corporativo con decenas de servidores o infraestructura de alta disponibilidad.
Su propósito es comprender los conceptos fundamentales de un SOC moderno utilizando hardware doméstico, herramientas Open Source y escenarios completamente controlados.
Lo aprendido
Diseñar la arquitectura antes de comenzar la instalación puede parecer un paso poco emocionante.
No hay máquinas virtuales funcionando.
No hay dashboards.
No existen alertas ni eventos de seguridad.
Sin embargo, considero que esta fase es una de las más importantes de todo el proyecto.
Cada decisión tomada hoy servirá como base para los capítulos que vendrán después.
Seguramente esta arquitectura cambiará.
Aparecerán nuevas necesidades.
Descubriré herramientas que todavía no conozco.
Y probablemente termine modificando varias de las decisiones iniciales.
Pero precisamente esa es la esencia de Homelab SOC.
No documentar únicamente el resultado.
Sino documentar todo el proceso.
En el siguiente capítulo comenzaremos a preparar el equipo anfitrión con Arch Linux para convertirlo en la base sobre la que funcionará todo el laboratorio.