Architettura (livello alto)

I servizi sono connessi su una rete Docker bridge dedicata (172.20.0.0/16 di default). È incluso un container attaccante per eseguire tentativi di sfruttamento controllati contro il servizio MindsDB isolato.

Porte (host → container)

• 80 → proxy nginx
• 443 → proxy nginx (se SSL abilitato)
• 8080 → dashboard reverse-proxy
• 47334 → MindsDB (API/web)
• 47335 → MindsDB (API/ausiliaria)
• 5432 → Postgres (interna, non consigliato esporla)
• 9200 → Elasticsearch
• 5601 → Kibana
• 1025/8025 → Mailhog (SMTP/web)

Di default Postgres non è pensata per essere esposta a internet pubblico. Il file compose mappa i servizi interni per l'uso nel laboratorio locale.

Avvio rapido (locale)

Prerequisiti:

• Docker (v20+) e Docker Compose v2+ (docker compose)
• Almeno 8 GB di RAM consigliati per una distribuzione completa (Elasticsearch + Kibana richiedono memoria)

1. Clonare il repository:

2. Copiare il file di ambiente di esempio e rivedere i segreti:

Importante: assicurarsi che DB_PASSWORD in .env corrisponda alla password che il file compose si aspetta. C'è un valore predefinito in docker-compose.yml (${DB_PASSWORD:-P@ssw0rd123!}). Impostare DB_PASSWORD=P@ssw0rd123! in .env oppure modificare docker-compose.yml per usare la password preferita. Se non corrispondono, MindsDB non riuscirà a connettersi a Postgres e i servizi non si avvieranno correttamente.

3. (Opzionale) Modificare .env per regolare il comportamento (abilitare/disabilitare funzionalità, impostare l'IP di ascolto dell'attaccante, ecc.).

4. Avviare il laboratorio (modalità completa):

5. Verificare questi endpoint una volta che i servizi sono sani:

• MindsDB: curl http://localhost:47334/api/status
• Kibana: http://localhost:5601
• Dashboard reverse proxy: http://localhost:8080

6. Per fermare e rimuovere i container:

Per rimuovere i volumi (distruttivo):

Profili e opzioni delle risorse

Il README fa riferimento a profili minimale e di monitoraggio. Per supportarli si può:

• Usare le chiavi profiles: in docker-compose.yml per separare i servizi nei profili minimal e monitoring, oppure
• Creare un file compose di override come docker-compose.minimal.yml che disabilita i componenti pesanti (Elasticsearch/Kibana/Wazuh) per test a basse risorse.

Un approccio minimale suggerito per i test è commentare o saltare Elasticsearch/Kibana/Wazuh ed eseguire solo: mindsdb, postgres, nginx-proxy e attacker.

Come funziona il laboratorio (dettagliato)

• Reverse proxy (nginx-proxy): funge da endpoint esterno e instrada il traffico dell'attaccante al servizio MindsDB vulnerabile. Il proxy fornisce anche una semplice dashboard sulla porta (8080) per controlli rapidi.

• MindsDB (immagine vulnerabile): impacchettato dalla release vulnerabile citata nel README. Memorizza i dati in Postgres e fornisce endpoint API che sono intenzionalmente vulnerabili nelle versioni precedenti.

• Postgres: memorizza la configurazione e gli artefatti di MindsDB. SQL di inizializzazione e dati seed sono forniti in configs/postgres/*.sql.

• Stack ELK (Elasticsearch, Logstash, Kibana): raccoglie i log dal proxy e dall'applicazione così da poter creare regole di rilevamento e dashboard.

• Wazuh (opzionale): agente e manager di monitoraggio della sicurezza. Incluso come segnaposto per dimostrare l'integrazione; i certificati TLS e le credenziali nella configurazione sono segnaposto e devono essere forniti per la piena funzionalità.

• Container attaccante: un ambiente con utilità (curl, netcat, python) e la cartella exploits/ montata per eseguire script di sfida dall'interno della stessa rete Docker (isolata dalla rete host se desiderato).

• Servizio di backup: container di esempio per dimostrare flussi di lavoro enterprise realistici (backup che estraggono dump del DB da Postgres).

Come usare il laboratorio (flusso di pratica)

1. Avviare il laboratorio (vedi Avvio rapido).
2. Dall'host, o entrando nel container attaccante (docker compose exec -it attacker /bin/bash), eseguire ricognizione contro il proxy (porta 80/8080) e l'API MindsDB (47334).
3. Progredire attraverso i livelli di apprendimento (ricognizione → path traversal → RCE → persistenza → difesa). Questo repository non include intenzionalmente codice exploit armato. Se si desiderano script di sfida o passaggi PoC sanitizzati, possiamo aggiungerli sotto exploits/ e docs/challenges/ con indicazioni e controlli di sicurezza.
4. Osservare i log in ELK e usare la regola Sigma inclusa (rules/sigma/cve-2026-27483.yml) come punto di partenza per i rilevamenti. Creare visualizzazioni Kibana per evidenziare percorsi di upload sospetti, richieste anomale e attività inattesa sul file system.

Esempio: eseguire una ricognizione di base dal container attaccante

Smoke test

Uno script di smoke test è fornito in scripts/smoke_test.sh (se presente). Esegue i seguenti controlli:

• Compila e avvia lo stack compose
• Attende che /api/status di MindsDB risponda
• Verifica che il reverse proxy nginx risponda sulla porta 8080
• Controlla l'endpoint di stato di Kibana
• Attende la salute del cluster Elasticsearch (yellow|green)
• Verifica la prontezza di Postgres con pg_isready

Eseguirlo localmente:

Se lo smoke test fallisce, raccogliere i log in smoke_compose_logs.txt e condividerli per il debug:

Rilevamento e registrazione

• La pipeline Logstash è fornita in configs/logstash/logstash.conf per inoltrare i log a Elasticsearch. La regola Sigma inclusa rules/sigma/cve-2026-27483.yml è un semplice esempio che segnala pattern di path traversal sospetti (richieste contenenti ..). Usarla come punto di partenza e perfezionarla per ridurre i falsi positivi.

• Creare dashboard Kibana per visualizzare:

  • URI di upload/richieste contenenti pattern di traversal
  • User agent e IP sorgente anomali
  • Modifiche nei log relativi al file system

Risoluzione dei problemi (problemi comuni)

• Errori di autenticazione Postgres: di solito dovuti a una mancata corrispondenza della password del DB tra .env e docker-compose.yml. Assicurarsi che entrambi concordino sullo stesso segreto.
• Errori MindsDB/500: controllare docker compose logs -f mindsdb per stack trace ed errori di connettività al DB.
• Elasticsearch OOM o che non si avvia: aumentare la RAM dell'host o ridurre ES_JAVA_OPTS in docker-compose.yml (esempio: -Xms256m -Xmx256m) per host piccoli.
• Healthcheck nginx che fallisce: assicurarsi che la configurazione del proxy punti all'host interno corretto (mindsdb:47334) e che il container mindsdb sia sano.

Se serve aiuto per il debug, eseguire lo smoke test e condividere smoke_compose_logs.txt.

Sicurezza e aspetti legali

• Il laboratorio include componenti intenzionalmente vulnerabili. Usarlo solo in ambienti isolati e non di produzione.
• Non distribuire questo laboratorio su infrastrutture instradabili pubblicamente.
• Tenere il codice exploit fuori dai commit pubblici; se si includono passaggi PoC, sanitizzarli e seguire pratiche di divulgazione responsabile.

Contributi

I contributi sono benvenuti. Modi suggeriti per aiutare:

• Migliorare la documentazione in docs/ (distribuzione, sfide, rilevamento, risposta agli incidenti)
• Aggiungere script di sfida sanitizzati in exploits/ con guide di apprendimento passo passo
• Aggiungere smoke test e workflow CI per validare il laboratorio su push/PR

Si prega di aprire PR verso main e seguire le linee guida CONTRIBUTING quando si aggiunge materiale exploit educativo.

Crediti

• Scoperta della vulnerabilità: XlabAITeam
• PoC originale: Lohitya Pushkar (thewhiteh4t)
• Sviluppo del laboratorio: Security Research Community

Fatto con ❤️ per la community della sicurezza.