Arquitectura (nivel alto)

Los servicios están conectados en una red Docker bridge dedicada (172.20.0.0/16 por defecto). Se incluye un contenedor de atacante para ejecutar intentos de explotación controlados contra el servicio MindsDB aislado.

Puertos (host → contenedor)

• 80 → proxy nginx
• 443 → proxy nginx (si SSL está habilitado)
• 8080 → panel del proxy inverso
• 47334 → MindsDB (API/web)
• 47335 → MindsDB (API/auxiliar)
• 5432 → Postgres (interno, no se recomienda exponer)
• 9200 → Elasticsearch
• 5601 → Kibana
• 1025/8025 → Mailhog (SMTP/web)

Por defecto, Postgres no está destinado a exponerse a internet público. El archivo compose mapea los servicios internos para uso local del laboratorio.

Inicio rápido (local)

Requisitos previos:

• Docker (v20+) y Docker Compose v2+ (docker compose)
• Se recomiendan al menos 8 GB de RAM para un despliegue completo (Elasticsearch + Kibana requieren memoria)

1. Clona el repositorio:

2. Copia el archivo de entorno de ejemplo y revisa los secretos:

Importante: Asegúrate de que DB_PASSWORD en .env coincida con la contraseña que espera el archivo compose. Hay un valor por defecto en docker-compose.yml (${DB_PASSWORD:-P@ssw0rd123!}). Establece DB_PASSWORD=P@ssw0rd123! en .env o edita docker-compose.yml para usar la contraseña que prefieras. Si no coinciden, MindsDB no podrá conectarse a Postgres y los servicios no se iniciarán correctamente.

3. (Opcional) Edita .env para ajustar el comportamiento (habilitar/deshabilitar funciones, establecer IP del listener del atacante, etc.).

4. Inicia el laboratorio (modo completo):

5. Verifica estos endpoints una vez que los servicios estén saludables:

• MindsDB: curl http://localhost:47334/api/status
• Kibana: http://localhost:5601
• Panel del proxy inverso: http://localhost:8080

6. Para detener y eliminar contenedores:

Para eliminar volúmenes (destructivo):

Perfiles y opciones de recursos

El README hace referencia a perfiles mínimo y de monitoreo. Para soportarlos, puedes:

• Usar claves profiles: en docker-compose.yml para separar los servicios en perfiles minimal y monitoring, o
• Crear un archivo compose de anulación como docker-compose.minimal.yml que deshabilite los componentes pesados (Elasticsearch/Kibana/Wazuh) para pruebas de bajos recursos.

Un enfoque mínimo sugerido para pruebas es comentar u omitir Elasticsearch/Kibana/Wazuh y ejecutar solo: mindsdb, postgres, nginx-proxy y attacker.

Cómo funciona el laboratorio (detallado)

• Proxy inverso (nginx-proxy): actúa como el endpoint orientado al exterior y enruta el tráfico del atacante al servicio vulnerable MindsDB. El proxy también proporciona un panel simple en el puerto 8080 para verificaciones rápidas.

• MindsDB (imagen vulnerable): empaquetado a partir de la versión vulnerable referenciada en el README. Almacena datos en Postgres y proporciona endpoints API que son intencionalmente vulnerables en versiones antiguas.

• Postgres: almacena la configuración y los artefactos de MindsDB. Se proporcionan SQL de inicialización y datos semilla en configs/postgres/*.sql.

• Stack ELK (Elasticsearch, Logstash, Kibana): recopila registros del proxy y de la aplicación para que puedas construir reglas de detección y paneles.

• Wazuh (opcional): agente y administrador de monitoreo de seguridad. Se incluye como marcador de posición para demostrar la integración; los certificados TLS y las credenciales en la configuración son marcadores de posición y deben aprovisionarse para su funcionalidad completa.

• Contenedor del atacante: un entorno con utilidades (curl, netcat, python) y la carpeta exploits/ montada para ejecutar scripts de desafío desde dentro de la misma red Docker (aislada de la red de tu host si así lo deseas).

• Servicio de respaldo: contenedor de muestra para demostrar flujos de trabajo empresariales realistas (respaldos que extraen volcados de la base de datos de Postgres).

Cómo usar el laboratorio (flujo de práctica)

1. Inicia el laboratorio (consulta Inicio rápido).
2. Desde tu host, o ingresando al contenedor del atacante (docker compose exec -it attacker /bin/bash), ejecuta reconocimiento contra el proxy (puerto 80/8080) y la API de MindsDB (47334).
3. Avanza a través de los niveles de aprendizaje (reconocimiento → path traversal → RCE → persistencia → defensa). Este repositorio intencionalmente no incluye código de explotación armado. Si deseas scripts de desafío o pasos de PoC saneados, podemos agregarlos en exploits/ y docs/challenges/ con orientación y verificaciones seguras.
4. Observa los registros en ELK y usa la regla Sigma incluida (rules/sigma/cve-2026-27483.yml) como punto de partida para las detecciones. Crea visualizaciones en Kibana para resaltar rutas de carga sospechosas, solicitudes anómalas y actividad inesperada del sistema de archivos.

Ejemplo: ejecuta un reconocimiento básico desde el contenedor del atacante

Pruebas de humo

Se proporciona un script de prueba de humo en scripts/smoke_test.sh (si está presente). Realiza las siguientes verificaciones:

• Construye e inicia el stack compose
• Espera a que /api/status de MindsDB responda
• Verifica que el proxy inverso nginx responda en el puerto 8080
• Comprueba el endpoint de estado de Kibana
• Espera la salud del clúster de Elasticsearch (amarillo|verde)
• Verifica la disponibilidad de Postgres con pg_isready

Ejecútalo localmente:

Si la prueba de humo falla, recopila los registros en smoke_compose_logs.txt y compártelos para depuración:

Detección y registro

• Se proporciona una canalización de Logstash en configs/logstash/logstash.conf para reenviar registros a Elasticsearch. La regla Sigma incluida rules/sigma/cve-2026-27483.yml es un ejemplo simple que marca patrones sospechosos de path traversal (solicitudes que contienen ..). Úsala como punto de partida y refínala para reducir falsos positivos.

• Crea paneles en Kibana para visualizar:

  • URIs de carga/solicitud que contengan patrones de traversal
  • Agentes de usuario y direcciones IP de origen anómalos
  • Cambios en los registros relacionados con el sistema de archivos

Solución de problemas (problemas comunes)

• Fallos de autenticación de Postgres: esto generalmente se debe a una discrepancia en la contraseña de la base de datos entre .env y docker-compose.yml. Asegúrate de que ambos coincidan con el mismo secreto.
• Errores/500 de MindsDB: revisa docker compose logs -f mindsdb para ver trazas de pila y errores de conectividad con la base de datos.
• Elasticsearch sin memoria (OOM) o que no inicia: aumenta la RAM del host o reduce ES_JAVA_OPTS en docker-compose.yml (ejemplo: -Xms256m -Xmx256m) para hosts pequeños.
• Fallo del healthcheck de Nginx: asegúrate de que la configuración del proxy apunte al host interno correcto (mindsdb:47334) y que el contenedor de mindsdb esté saludable.

Si necesitas ayuda para depurar, ejecuta la prueba de humo y comparte smoke_compose_logs.txt.

Seguridad y legal

• El laboratorio incluye componentes intencionalmente vulnerables. Úsalo solo en entornos aislados y que no sean de producción.
• No despliegues este laboratorio en infraestructura enrutable públicamente.
• Mantén el código de explotación fuera de los commits públicos; si incluyes pasos de PoC, sánalos y sigue prácticas de divulgación responsable.

Contribuciones

Las contribuciones son bienvenidas. Formas sugeridas de ayudar:

• Mejorar la documentación en docs/ (despliegue, desafíos, detección, respuesta a incidentes)
• Agregar scripts de desafío saneados en exploits/ con guías de aprendizaje paso a paso
• Agregar pruebas de humo y flujos de trabajo de CI para validar el laboratorio en push/PR

Abre PRs contra main y sigue las pautas de CONTRIBUTING cuando agregues material educativo de explotación.

Créditos

• Descubrimiento de la vulnerabilidad: XlabAITeam
• PoC original: Lohitya Pushkar (thewhiteh4t)
• Desarrollo del laboratorio: Comunidad de Investigación en Seguridad

Hecho con ❤️ para la comunidad de seguridad.