This repository is part of the Programa Global de Innovación en Seguridad for the promotion of Cátedras de Ciberseguridad en España, funded by the European Union NextGeneration-EU Funds, through the Instituto Nacional de Ciberseguridad (INCIBE).
Este repositorio contiene la versión demo y experimental de NICS | CyberLab, un entorno de laboratorio automatizado diseñado para pruebas, formación y experimentación en ciberseguridad. El proyecto permite desplegar rápidamente la infraestructura base del laboratorio mediante un único script de instalación y ejecutar módulos adicionales de prueba, como la PoC de OpenStack + Snort 3.
NICS | CyberLab es un laboratorio automatizado orientado a capacitación en ciberseguridad, diseñado para entrenar un flujo realista de un entorno SOC:
detección → investigación → mejora → reporte
El repositorio le permite desplegar infraestructura (OpenStack), levantar escenarios por niveles (ej. Level-01: Mini SOC con Snort + Wazuh + Caldera) y dejar trazabilidad completa en logs para documentar evidencias.
ℹ️ Nota: todo lo incluido está pensado para un entorno de laboratorio autorizado y controlado. No reutilice técnicas o automatizaciones fuera del contexto permitido.
- 1. Qué ofrece este repositorio
- 2. Requisitos mínimos y recomendados
- 3. Estructura del proyecto
- 4. Flujo recomendado (Quickstart)
- 5. Logs y resúmenes (evidencias)
- 6. Scripts principales y para qué sirven
- 7. Artefactos generados (deploy/ y admin-openrc.sh)
- 8. Limpieza del entorno (automática y manual)
- 9. Operación manual y recuperación
- 10. Niveles y ejercicios
- 11. Buenas prácticas
Este repositorio le permite:
- Preparar el host y desplegar la base del laboratorio con un único script.
- Desplegar OpenStack + recursos (imágenes, redes, flavors, SG, keypair) de forma automatizada.
- Levantar escenarios por niveles (por ejemplo
lab/level-01.sh). - Obtener logs y un resumen final con datos operativos (IPs/URLs/credenciales).
- Limpiar el entorno de forma controlada (desde “solo el nivel” hasta “borrar OpenStack del host”).
- Mínimo funcional: configuración que permite que el laboratorio funcione con fluidez en una máquina local.
- Recomendado: configuración pensada para trabajar con más estabilidad, repetir despliegues con frecuencia y disponer de margen de crecimiento para niveles y escenarios con más componentes simultáneos.
| Recurso | Mínimo funcional | Recomendado |
|---|---|---|
| CPU | 8 vCPU | 16 vCPU |
| RAM | 16 GB | 32 GB |
| Disco | 120 GB SSD | 240–300 GB SSD/NVMe |
| Virtualización | Soportada por CPU y habilitada (AMD-V/VT-x) | Soportada por CPU y habilitada (AMD-V/VT-x) |
| SO | Linux 64 bits (Ubuntu 24.04) | Linux 64 bits (Ubuntu 24.04) |
| Red | NAT funcional | Bridge recomendado |
💡 Recomendación: si su objetivo es desplegar niveles con varias máquinas o repetir prácticas con frecuencia, use el perfil Recomendado y disco NVMe.
Activación de virtualización anidada (nested VT-x/AMD-V) en Windows 11 con VMware Workstation/Player
Este ajuste se usa cuando necesitas que una VM pueda crear y arrancar otras máquinas dentro. Si esa capacidad no está disponible, lo normal es que las instancias no terminen de arrancar y aparezcan errores del hipervisor. En Windows 11, algunas funciones de virtualización que vienen activadas pueden interferir con VMware y evitar que se pueda activar esta opción; por eso se desactivan antes.
-
La máquina virtual debe de estar apagada obligatoriamente.
-
Virtualización activada en BIOS/UEFI
En Windows 11 puedes comprobarlo así:
- Administrador de tareas → Rendimiento → CPU → “Virtualización: Habilitada”
Si aparece “Deshabilitada”, actívalo en BIOS/UEFI (Intel VT-x / AMD-V / SVM).
En algunas instalaciones, Windows deja activadas funciones que hacen que VMware no pueda usar VT-x “en exclusivo”, y eso puede impedir que puedas virtualizar dentro de una VM.
-
Abre Panel de control
-
Ve a Programas → Programas y características
-
Busca: Activar o desactivar las características de Windows
-
Desmarca (si están marcadas) estas opciones:
- Hyper-V
- Plataforma de hipervisor de Windows (Windows Hypervisor Platform)
- Plataforma de máquina virtual (Virtual Machine Platform)
- Windows Sandbox (si aparece)
- Microsoft Defender Application Guard (si aparece)
- Containers (si aparece y no lo necesitas)
- (Opcional pero común) Subsystem for Linux (WSL) si estás usando WSL2 (porque suele ir ligado a Virtual Machine Platform)
-
Acepta y reinicia.
ℹ️ Nota: si desactivas Virtual Machine Platform / Hypervisor Platform, puede dejar de funcionar WSL2 y otras funciones que dependan de Hyper-V. Es el “precio” habitual para que VMware tenga control total de VT-x y permita nested.
Esto también puede interferir en algunos equipos:
- Seguridad de Windows
- Seguridad del dispositivo
- Aislamiento del núcleo → Detalles
- Desactiva "Integridad de memoria"
- Reinicia
ℹ️ Nota: Si no lo ves, puede estar gestionado por política o el fabricante.
- Abre VMware
- Selecciona la VM → Settings → Processors
- Marca:
- [✓] Virtualize Intel VT-x/EPT or AMD-V/RVI
- Acepta y arranca la VM.
-
¿La VM está apagada?
-
¿Has reiniciado tras desmarcar features?
-
¿En Administrador de tareas se muestra “Virtualización: Habilitada”?
-
Ejecuta esto para ver si Windows aún detecta hipervisor activo:
En CMD:
systeminfo | findstr /i "Hyper-V"
Si ves algo así: “Se detectó un hipervisor”, entonces Hyper-V/VBS sigue activo (revise lo anterior).
Tras un despliegue completo, el repositorio queda típicamente así:
.
├── admin-openrc.sh
├── cyberlab.sh
├── cyberlab-uninstall.sh
├── deploy/
│ ├── openstack-install.sh
│ ├── openstack-resources.sh
│ ├── setup-veth.sh
│ ├── uplinkbridge.sh
│ ├── openstack_venv/
│ ├── img/
│ ├── keys/
│ └── cloud-init/
├── gui/ # Dashboard (demo de referencia)
├── inst/ # Operaciones por componente
├── lab/
│ ├── level-01.sh
│ └── README.md
├── log/
│ ├── cyberlab.log
│ ├── dashboard.log
│ └── level.log
├── preflight-check.sh
├── services_restart.sh
├── set-env.sh
└── undeploy/
├── level-01-uninstall.sh
├── openstack-resources-uninstall.sh
├── openstack-uninstall.sh
├── uplinkbridge-uninstall.sh
├── admin-openrc_uninstall.sh
└── clean-inst.sh
ℹ️ Nota: la carpeta
log/se crea tras ejecutar scripts. No aparece en un clonado “en limpio”.
⚠️ Advertencia: Despliegue evaluado en Ubuntu 24.04.
Clone el repositorio:
git clone https://github.com/crismillan06/nics-cyberlab.git
cd nics-cyberlabCompruebe permisos de ejecución. Si ve x (ej. -rwxr-xr-x), puede omitir cualquier chmod +x:
ls -lh *.sh
ls -lh deploy/*.sh inst/*.sh lab/*.sh gui/*.sh undeploy/*.shSi faltan permisos, aplíquelos una vez:
chmod +x *.sh
chmod +x deploy/*.sh inst/*.sh lab/*.sh gui/*.sh undeploy/*.sh💡 Recomendación: aunque un script no sea ejecutable, siempre puede lanzarlo con
bash script.sh. Aun así, mantener permisos correctos evita errores de “Permission denied”.
bash cyberlab.shRevise el resumen final:
tail -n 120 log/cyberlab.logℹ️ Nota: si relanza el despliegue,
cyberlab.shpuede generar backups tipolog/cyberlab.log-YYYYMMDD-HHMM.bak.
Si ya ejecutó cyberlab.sh, no es necesario lanzar este paso: el dashboard demo se inicia automáticamente en segundo plano.
Si necesita relanzarlo:
bash gui/start_dashboard.sh
tail -f log/dashboard.log
⚠️ Advertencia:gui/es una demo de referencia. Útil para pruebas rápidas, pero no forma parte del núcleo operativo del laboratorio.
bash lab/level-01.sh
tail -n 200 log/level.log💡 Recomendación: use
log/level.logcomo “salida operativa”: ahí suele tener IPs, URLs y credenciales del escenario.
La carpeta log/ se genera tras ejecutar scripts y deja trazabilidad para documentación (tiempos, endpoints y credenciales).
| Fase | Script | Log | Qué encontrará |
|---|---|---|---|
| Deploy base | cyberlab.sh |
log/cyberlab.log |
Acciones, validaciones y resumen final |
| Dashboard demo | gui/start_dashboard.sh |
log/dashboard.log |
Estado/puertos del servicio demo y errores |
| Nivel | lab/level-01.sh |
log/level.log |
Datos operativos del nivel + outputs |
Búsqueda rápida de fallos típicos:
grep -iE "error|fail|fatal|traceback|exception|warn" log/*.log | tail -n 120ℹ️ Nota: un laboratorio “sano” suele reflejarlo en el resumen final (IPs y endpoints coherentes). Si el resumen está incompleto, empiece por el primer error relevante del log.
-
cyberlab.sh: orquesta el despliegue completo y deja resumen enlog/cyberlab.log. -
preflight-check.sh: valida host (recursos, red, virtualización) para evitar fallos repetidos. -
set-env.sh: prepara el modo CLI en un paso:- activa
deploy/openstack_venv(para disponer deopenstack), - carga
admin-openrc.sh(variablesOS_*).
- activa
-
services_restart.sh: recuperación cuando OpenStack queda en estado inconsistente (servicios/containers caídos). -
inst/: operaciones por componente (Snort/Wazuh/Caldera y combinaciones).💡 Recomendación: use
lab/level-01.shsalvo que esté depurando un componente concreto. -
lab/level-01.sh: despliega el “Mini SOC” y consolida salida enlog/level.log.
Archivo de variables OS_* para autenticación OpenStack.
ℹ️ Nota: el laboratorio se apoya en un entorno virtual (venv) para mantener el host limpio y evitar dependencias globales.
Uso manual por pasos:
source deploy/openstack_venv/bin/activate
source admin-openrc.sh
openstack token issue
deactivate💡 Recomendación: use
source set-env.shpara activar venv y cargar credenciales en un único paso.
openstack_venv/→ herramientas OpenStack CLI y dependencias.img/→ imágenes base descargadas/convertidas.keys/→ claves (ej.my_key.pem) para acceso a instancias.cloud-init/→ plantillas/credenciales iniciales.openstack-install.sh/openstack-resources.sh→ instalación y creación de recursos.uplinkbridge.sh/setup-veth.sh→ red auxiliar del host (si aplica).
bash cyberlab-uninstall.sh💡 Recomendación: use esta opción si su objetivo es volver a un estado limpio sin preocuparse del orden.
- Nivel:
bash undeploy/level-01-uninstall.sh- Recursos OpenStack del stack:
bash undeploy/openstack-resources-uninstall.sh- OpenStack/Kolla/Docker del host:
sudo bash undeploy/openstack-uninstall.sh --safe- Red auxiliar/OVS/veth (host “como antes”):
sudo bash undeploy/uplinkbridge-uninstall.shbash undeploy/clean-inst.sh --force
⚠️ Advertencia:--all-projectsborra instancias en todos los proyectos (solo admin). Úselo únicamente en laboratorio y sabiendo exactamente qué hace.
Este apartado le permite verificar el estado, consultar recursos clave y reaccionar si algo no responde, sin depender del despliegue automático.
source set-env.shℹ️ Nota: si falla, lo más habitual es que falte
deploy/openstack_venv/oadmin-openrc.sh.
openstack token issue- Si devuelve token: [✓] credenciales correctas.
- Si no conecta: revise servicios (siguiente punto).
openstack server list
openstack network list
openstack floating ip list💡 Recomendación: si aquí todo es coherente (instancias activas y redes correctas), el nivel suele estar operativo.
bash services_restart.sh
source set-env.sh
openstack token issue
⚠️ Advertencia: si tras reiniciar servicios sigue fallando, revise los logs (especialmente el primer error real, no el efecto cascada).
Los ejercicios y el enfoque formativo están documentados en:
📌 lab/README.md
Actualmente existe Level-01 enfocado a prácticas SOC; NICS | CyberLab está diseñado para crecer con Level-02/03 y más escenarios.
- Ejecute scripts desde la raíz del repositorio.
- Conserve
log/como evidencia de práctica. - No reutilice automatizaciones fuera de laboratorio.
- Use
source set-env.shpara evitar problemas de rutas/venv y credenciales. - Realice snapshot de la VM antes de cambios grandes.
Proyecto para entornos de laboratorio y formación en ciberseguridad.