🎯 Problématique #
L’objectif de ce projet était de mettre en place un environnement d’hébergement performant, isolé et sécurisé pour un serveur de jeu Minecraft avec le mod Create v6, s’exécutant sur un VPS distant.
Contraintes techniques :
- Assurer la cohabitation parfaite du serveur de jeu avec les services web pré-existants de la machine (notamment un serveur web Nginx) sans conflits de ports, d’utilisateurs ou de dépendances Java.
- Analyser l’allocation des ressources matérielles en conditions réelles pour éliminer les fuites de mémoire et les freezes de l’infrastructure.
- Sécuriser l’accès au port de jeu contre les robots scanneurs automatisés du web sans perturber les outils de détection de paquets malveillants.
├── Hôte Linux (UFW Firewall & Fail2ban actif)
├── Serveur Web Nginx (Production existante)
└── Conteneur Docker Isolé (minecraft-create-server)
├── Moteur de jeu : NeoForge 21.1.230
├── Port de jeu mappé : (TCP/UDP)
└── Volume persistant lié : ./data:/data (UID:GID 1000)
🖥️ Étape 1 — Préparation de l’environnement hôte #
Le déploiement s’effectue dans un répertoire dédié au sein de l’espace utilisateur de la machine Linux, garantissant une isolation totale des fichiers de configuration.
mkdir ~/minecraft-server
cd ~/minecraft-serverPour des raisons évidentes de sécurité, le port SSH standard de l’hôte a été modifié dans la configuration système du démon SSH (/etc/ssh/sshd_config), limitant grandement la surface d’attaque et les scans de force brute automatisés.
📦 Étape 2 — Orchestration de la Stack via Docker Compose #
Pour assurer une isolation stricte des ressources, le serveur de jeu est orchestré par le biais d’un fichier docker-compose.yml. Cette approche évite d’installer manuellement un runtime Java (JDK 21) directement sur le système hôte, éliminant tout risque de conflit de dépendances avec les services existants.
docker-compose.yml
L'image itzg/minecraft-server encapsule le runtime JVM dans le conteneur. Nginx sur l'hôte reste totalement indépendant — aucune dépendance Java partagée, aucun conflit de ports système.
⚙️ Étape 3 — Injection sécurisée des Mods (Contournement CurseForge) #
Le mod Create v6 (6.0.10) requiert l’injection d’un binaire Java .jar dans l’arborescence persistante du serveur. Suite au blocage systématique des outils d’extraction automatisés (wget / curl) par les serveurs de protection de CurseForge (erreurs HTTP 403 / 404), un protocole de transfert sécurisé local-à-distant a été mis en œuvre.
1. Téléchargement et transfert via SCP #
Le fichier create-1.21.1-6.0.10.jar a été téléchargé localement sur la machine de gestion Windows, puis poussé via SSH dans la zone tampon de l’utilisateur distant :
:: Exécuté depuis l'invite de commande Windows locale
scp -P port create-1.21.1-6.0.10.jar lucas@ip_du_vps:/home/lucas/
2. Déplacement et remédiation des droits (Permissions Linux) #
Par défaut, le dossier persistant ./data/mods créé à la volée par Docker appartient à un UID/GID interne restreint (1000:1000). Les commandes suivantes réalignent la propriété du fichier pour le conteneur :
# Déplacement en mode privilégié vers le répertoire de montage
sudo mv /home/lucas/create-1.21.1-6.0.10.jar /home/lucas/minecraft-server/data/mods/
# Remédiation récursive de la propriété pour le conteneur Docker
sudo chown -R 1000:1000 /home/lucas/minecraft-server/data/mods/🔩 Étape 4 — Gestion des Ressources et Résolution d’Anomalie #
Pendant la phase de validation, une déconnexion brutale de type java.net.SocketException: Connection reset a mis en évidence une saturation totale de l’infrastructure.
L’analyse des métriques en direct via l’outil d’inspection de Docker :
docker stats
CPU : 234.38%
Cause : boucle infinie du Garbage Collector Java — insuffisance de RAM provoquant un gel réseau total et le rejet des sockets (
getsockopt).MEMORY rehaussée : 5G → 6GGarde-fou OOM : limits.memory: 6.5G
Résultat : stabilité des processus et consommation CPU nominale rétablie instantanément.
🐍 Étape 5 — Administration via Contextes Sécurisés #
En raison des restrictions de sécurité intégrées à l’image applicative, l’envoi de commandes d’administration depuis la console hôte a exigé l’alignement de l’UID d’exécution.
Pour attribuer les privilèges d’opérateur en jeu sans ouvrir l’accès shell racine :
# Injection d'instructions console via le descripteur d'identité 1000
docker exec -i --user 1000 minecraft-create-server mc-send-to-console op PseudoL’argument --user 1000 garantit que la commande s’exécute dans le même contexte de sécurité que le processus Java du serveur — sans jamais élever les privilèges au niveau root.
📊 Étape 6 — Sécurisation du Réseau & Filtrage Firewall #
L’ouverture d’un point d’accès public sur la couche de transport impose de solides mécanismes de défense en profondeur. Une stratégie multiniveau a été déployée pour contrer les scanners automatiques et les tentatives de déni de service.
✅ Résultats & Bilan #
Ce projet de laboratoire d’infrastructure démontre la viabilité d’une solution d’hébergement d’application conteneurisée à fortes contraintes matérielles dans un contexte de Game Hosting.
Ce qui a été accompli :
- ✔ Déploiement complet d’un serveur Minecraft modifié NeoForge via Docker sur VPS OVHcloud
- ✔ Cohabitation sans conflit entre le conteneur de jeu et le serveur Nginx en production
- ✔ Résolution d’une saturation mémoire JVM critique diagnostiquée via
docker stats - ✔ Mise en place d’un pipeline de transfert de mods sécurisé contournant les restrictions CurseForge
- ✔ Sécurisation périmétrique du serveur (UFW + Fail2ban + port SSH non-standard)
- ✔ Administration console isolée sans privilèges root grâce au contexte UID Docker
L’isolation des services via Docker garantit le maintien des performances de la plateforme web principale (Nginx) tout en offrant un environnement robuste, supervisé et sécurisé pour l’exécution d’applications tierces.