Architecture (vue d'ensemble)

Les services sont connectés sur un réseau Docker bridge dédié (172.20.0.0/16 par défaut). Un conteneur attaquant est inclus pour exécuter des tentatives d'exploitation contrôlées contre le service MindsDB isolé.

Ports (hôte → conteneur)

• 80 → proxy nginx
• 443 → proxy nginx (si SSL activé)
• 8080 → tableau de bord du reverse proxy
• 47334 → MindsDB (API/web)
• 47335 → MindsDB (API/auxiliaire)
• 5432 → Postgres (interne, exposition non recommandée)
• 9200 → Elasticsearch
• 5601 → Kibana
• 1025/8025 → Mailhog (SMTP/web)

Par défaut, Postgres n'est pas destiné à être exposé sur Internet. Le fichier compose mappe les services internes pour une utilisation locale en laboratoire.

Démarrage rapide (local)

Prérequis :

• Docker (v20+) et Docker Compose v2+ (docker compose)
• Au moins 8 Go de RAM recommandés pour un déploiement complet (Elasticsearch + Kibana nécessitent de la mémoire)

1. Cloner le dépôt :

2. Copier le fichier d'environnement d'exemple et vérifier les secrets :

Important : Assurez-vous que DB_PASSWORD dans .env correspond au mot de passe attendu par le fichier compose. Il existe une valeur par défaut dans docker-compose.yml (${DB_PASSWORD:-P@ssw0rd123!}). Définissez DB_PASSWORD=P@ssw0rd123! dans .env ou modifiez docker-compose.yml pour utiliser le mot de passe de votre choix. En cas de non-correspondance, MindsDB ne pourra pas se connecter à Postgres et les services ne démarreront pas correctement.

3. (Facultatif) Modifier .env pour ajuster le comportement (activer/désactiver des fonctionnalités, définir l'adresse IP d'écoute de l'attaquant, etc.).

4. Démarrer le laboratoire (mode complet) :

5. Vérifier ces points de terminaison une fois les services sains :

• MindsDB : curl http://localhost:47334/api/status
• Kibana : http://localhost:5601
• Tableau de bord du reverse proxy : http://localhost:8080

6. Pour arrêter et supprimer les conteneurs :

Pour supprimer les volumes (destructif) :

Profils et options de ressources

Le README fait référence aux profils minimal et surveillance. Pour les prendre en charge, vous pouvez soit :

• Utiliser les clés profiles: dans docker-compose.yml pour séparer les services en profils minimal et monitoring, ou
• Créer un fichier compose de remplacement tel que docker-compose.minimal.yml qui désactive les composants lourds (Elasticsearch/Kibana/Wazuh) pour les tests à faibles ressources.

Une approche de test minimal suggérée consiste à commenter ou ignorer Elasticsearch/Kibana/Wazuh et à exécuter uniquement : mindsdb, postgres, nginx-proxy et attacker.

Comment fonctionne le laboratoire (détaillé)

• Reverse proxy (nginx-proxy) : agit comme point de terminaison orienté vers l'extérieur et achemine le trafic de l'attaquant vers le service MindsDB vulnérable. Le proxy fournit également un simple port de tableau de bord (8080) pour des vérifications rapides.

• MindsDB (image vulnérable) : empaqueté à partir de la version vulnérable référencée dans le README. Il stocke les données dans Postgres et fournit des points de terminaison API intentionnellement vulnérables dans les versions plus anciennes.

• Postgres : stocke la configuration et les artefacts de MindsDB. Le SQL d'initialisation et les données de départ sont fournis dans configs/postgres/*.sql.

• Pile ELK (Elasticsearch, Logstash, Kibana) : collecte les journaux du proxy et de l'application afin que vous puissiez créer des règles de détection et des tableaux de bord.

• Wazuh (facultatif) : agent et gestionnaire de surveillance de sécurité. Inclus comme espace réservé pour démontrer l'intégration ; les certificats TLS et les identifiants dans la configuration sont des espaces réservés et doivent être provisionnés pour une fonctionnalité complète.

• Conteneur attaquant : un environnement avec des utilitaires (curl, netcat, python) et le dossier exploits/ monté pour exécuter des scripts de défi depuis l'intérieur du même réseau Docker (isolé de votre réseau hôte si souhaité).

• Service de sauvegarde : conteneur d'exemple pour démontrer des flux de travail d'entreprise réalistes (sauvegardes extrayant des dumps de base de données depuis Postgres).

Comment utiliser le laboratoire (flux de pratique)

1. Démarrer le laboratoire (voir Démarrage rapide).
2. Depuis votre hôte, ou en entrant dans le conteneur attaquant (docker compose exec -it attacker /bin/bash), effectuez une reconnaissance contre le proxy (port 80/8080) et l'API MindsDB (47334).
3. Progressez à travers les niveaux d'apprentissage (reconnaissance → traversée de chemin → RCE → persistance → défense). Ce dépôt n'inclut intentionnellement pas de code d'exploitation armé. Si vous souhaitez des scripts de défi ou des étapes de PoC assainies, nous pouvons les ajouter sous exploits/ et docs/challenges/ avec des conseils et des vérifications de sécurité.
4. Observez les journaux dans ELK et utilisez la règle Sigma incluse (rules/sigma/cve-2026-27483.yml) comme point de départ pour les détections. Créez des visualisations Kibana pour mettre en évidence les chemins de téléversement suspects, les requêtes anormales et l'activité inattendue du système de fichiers.

Exemple : exécuter une reconnaissance de base depuis le conteneur attaquant

Tests de fumée

Un script de test de fumée est fourni à scripts/smoke_test.sh (s'il est présent). Il effectue les vérifications suivantes :

• Construit et démarre la pile compose
• Attend que MindsDB /api/status réponde
• Vérifie que le reverse proxy nginx répond sur le port 8080
• Vérifie le point de terminaison de statut Kibana
• Attend la santé du cluster Elasticsearch (jaune|vert)
• Vérifie la disponibilité de Postgres avec pg_isready

Exécutez-le localement :

Si le test de fumée échoue, collectez les journaux dans smoke_compose_logs.txt et partagez-les pour le débogage :

Détection et journalisation

• Un pipeline Logstash est fourni dans configs/logstash/logstash.conf pour transférer les journaux vers Elasticsearch. La règle Sigma incluse rules/sigma/cve-2026-27483.yml est un exemple simple qui signale les modèles suspects de traversée de chemin (requêtes contenant ..). Utilisez-la comme point de départ et affinez-la pour réduire les faux positifs.

• Créez des tableaux de bord Kibana pour visualiser :

  • Les URI de téléversement/requête contenant des modèles de traversée
  • Les agents utilisateur et adresses IP sources anormaux
  • Les changements dans les journaux liés au système de fichiers

Dépannage (problèmes courants)

• Échecs d'authentification Postgres : cela est généralement dû à une non-correspondance du mot de passe de la base de données entre .env et docker-compose.yml. Assurez-vous que les deux utilisent le même secret.
• Erreurs MindsDB/500 : vérifiez docker compose logs -f mindsdb pour les traces de pile et les erreurs de connectivité de la base de données.
• Elasticsearch OOM ou ne démarre pas : augmentez la RAM de l'hôte ou réduisez ES_JAVA_OPTS dans docker-compose.yml (exemple : -Xms256m -Xmx256m) pour les petits hôtes.
• Échec du healthcheck nginx : assurez-vous que la configuration du proxy pointe vers le bon hôte interne (mindsdb:47334) et que le conteneur mindsdb est sain.

Si vous avez besoin d'aide pour le débogage, exécutez le test de fumée et partagez smoke_compose_logs.txt.

Sécurité et aspects légaux

• Le laboratoire inclut des composants intentionnellement vulnérables. Utilisez-le uniquement dans des environnements isolés et non destinés à la production.
• Ne déployez pas ce laboratoire sur une infrastructure routable publiquement.
• Gardez le code d'exploitation hors des commits publics ; si vous incluez des étapes de PoC, assainissez-les et suivez les pratiques de divulgation responsable.

Contribution

Les contributions sont les bienvenues. Façons suggérées d'aider :

• Améliorer la documentation sous docs/ (déploiement, défis, détection, réponse aux incidents)
• Ajouter des scripts de défi assainis dans exploits/ avec des guides d'apprentissage étape par étape
• Ajouter des tests de fumée et des workflows CI pour valider le laboratoire lors des push/PR

Veuillez ouvrir des PR vers main et suivre les directives CONTRIBUTING lorsque vous ajoutez du matériel d'exploitation pédagogique.

Crédits

• Découverte de la vulnérabilité : XlabAITeam
• PoC original : Lohitya Pushkar (thewhiteh4t)
• Développement du laboratoire : Security Research Community

Fait avec ❤️ pour la communauté de la sécurité.