R3 - Architecture sécurisée d'un serveur de jeu en ligne (PalmitoRP)

1. Contexte

PalmitoRP est un serveur de jeu communautaire basé sur FiveM (une modification multijoueur de GTA V) qui propose une expérience de Roleplay persistant. Concrètement, des joueurs se connectent en même temps et interagissent dans un monde virtuel avec des systèmes complexes : métiers, économie, police, hôpital, justice, etc.

L'infrastructure repose sur :

• Un serveur de jeu FiveM avec le runtime FXServer
• Une base MySQL/MariaDB qui stocke les comptes joueurs, inventaires, véhicules, propriétés, casiers judiciaires, progression
• Un panel d'admin txAdmin pour gérer le serveur en temps réel
• Un système de voix in-game (protocole Mumble via pma-voice)

L'enjeu, c'est que les serveurs FiveM populaires se font régulièrement DDoS, c'est-à-dire des attaques par déni de service, soit volumétriques (L3/L4), soit applicatives (L7). L'infrastructure devait aussi garantir la confidentialité des données joueurs et la continuité du service.

2. Ce que je voulais réussir

J'ai pris en charge la conception et le déploiement complet de l'infrastructure avec ces objectifs :

• Une architecture multi-couches qui résiste aux DDoS (L3/L4 et L7)
• Cacher l'IP réelle du backend (jamais exposée publiquement)
• Sécuriser tous les accès admin (SSH, base de données, panel txAdmin)
• Automatiser les sauvegardes et avoir un plan de reprise (PRA)
• Optimiser le téléchargement des ressources (50 à 500 Mo par joueur à chaque connexion) via un CDN
• Documenter tout pour pouvoir remonter l'infrastructure en moins de 30 minutes en cas de incident

3. Comment je m'y suis pris

3.1 Conception de l'architecture

J'ai séparé strictement trois flux :

L'admin (txAdmin, SSH, MySQL) passe par des canaux dédiés et isolés : Cloudflare Tunnel pour le panel web, SSH par clé pour le shell, tunnel SSH pour la base.

3.2 Protection DDoS multi-couches

Couche L3/L4 : tunnel GRE via X4B

Le tunnel GRE (Generic Routing Encapsulation) crée un lien réseau virtuel entre l'infrastructure X4B et le backend. Tout le trafic gameplay (TCP/UDP) passe par X4B qui filtre les paquets malveillants avant de les envoyer au backend via le tunnel.

• IP publique filtrée X4B : 198.251.84.71
• IP tunnel interne : 10.16.0.34/30 (invisible de l'extérieur)
• Script automatisé tunnel.sh qui se relance au boot via systemd

J'ai pris le GRE plutôt qu'un reverse proxy classique pour garder les vraies IP des joueurs (nécessaire pour l'anti-cheat FiniAC et le système de bans).

Couche L7 : Cloudflare Tunnel (Zero Trust)

Plutôt que d'ouvrir des ports pour le panel admin et l'endpoint HTTPS, j'ai mis un tunnel Cloudflare. Le démon cloudflared installé sur le backend ouvre une connexion sortante chiffrée vers Cloudflare. Résultat : aucun port entrant n'est exposé.

3.3 Sécurisation du backend

Firewall iptables avec policy DROP par défaut, par défaut, tout est bloqué :

• SSH (port 22) uniquement depuis mon IP d'admin
• Protocole GRE uniquement depuis l'endpoint X4B
• Trafic TCP/UDP FiveM uniquement depuis l'interface tunnel gre+
• txAdmin (40120) et MySQL (3306) uniquement depuis localhost
• MSS clamping sur l'interface GRE pour éviter la fragmentation

Firewall Hetzner Cloud, deuxième couche au niveau de l'hyperviseur Hetzner, qui filtre avant même qu'iptables ne soit sollicité.

Sécurisation SSH :

• Auth par clé ED25519 uniquement (mot de passe désactivé)
• PermitRootLogin: prohibit-password
• MaxAuthTries: 3
• Fail2ban actif (ban 3600s après 3 échecs)

Sécurisation MySQL :

• Port 3306 fermé au monde
• Accès uniquement via tunnel SSH dans HeidiSQL (plink.exe + clé .ppk)

Hardening sysctl : SYN cookies, optimisation des buffers réseau, reverse path filtering, désactivation des redirections ICMP et du source routing.

3.4 CDN et optimisation des téléchargements

Les joueurs téléchargent 50 à 500 Mo de ressources à chaque connexion. Sans cache, chacun télécharge depuis le backend et la bande passante explose.

Ma solution :

• Directive fileserver_add dans la configuration FiveM qui redirige les téléchargements vers cdn.palmitorp.com
• Cache Cloudflare avec un Edge TTL de 2 heures
• Le premier joueur télécharge depuis le backend (MISS), les suivants depuis le PoP Cloudflare le plus proche (HIT)

Purge automatique du cache : un script purge-cache.sh appelle l'API Cloudflare pour purger le cache. Il se lance automatiquement à chaque redémarrage de FiveM via ExecStartPost dans le service systemd, ce qui garantit aux joueurs des ressources toujours à jour après une modification.

3.5 Sauvegardes automatisées

J'ai mis une double politique de sauvegarde :

Backup MySQL → Storage Box Hetzner (script backup.sh lancé par cron toutes les 12 heures à 04:00 et 16:00) :

• mysqldump de la base
• Envoi du dump vers la Storage Box Hetzner via SCP (clé SSH dédiée, port 23)
• Suppression des backups locaux de plus de 7 jours
• Notification Discord via webhook (succès/échec, taille, espace disque restant)

Backup Hetzner Cloud : sauvegardes quotidiennes de l'image serveur complète (1,40 €/mois) → restauration complète possible en 1 clic.

3.6 Orchestration systemd

Plutôt que de gérer chaque composant à la main, j'ai centralisé tout dans le service systemd fivem.service :

ExecStartPre  : bash /root/tunnel.sh           (relance le tunnel GRE X4B)
ExecStartPre  : systemctl restart cloudflared  (relance le tunnel Cloudflare)
ExecStartPre  : sleep 3                        (attente de stabilisation)
ExecStart     : bash /home/fivem/fxserver/run.sh
ExecStartPost : bash /root/purge-cache.sh      (purge le cache CDN)

Un seul systemctl restart fivem et toute l'infrastructure repart proprement.

4. Ce que j'ai produit

• Schéma d'architecture complet (3 flux séparés, multi-couches)
• Configuration iptables avec policy DROP et règles documentées
• Scripts bash : tunnel.sh (tunnel GRE), backup.sh (sauvegardes), purge-cache.sh (purge CDN)
• Configuration systemd qui orchestre tunnel GRE + Cloudflare Tunnel + serveur FiveM + purge cache
• Configuration Cloudflare : DNS, tunnel Zero Trust, règles de cache, certificat SSL Origin
• Documentation technique de reconstruction pour remonter l'infrastructure en ~30 minutes
• Procédure de supervision via webhooks Discord (alertes backups, espace disque)

Schéma d'architecture, configurations et scripts détaillés présentés ci-dessous et démontrables à l'oral sur l'environnement réel.

5. Résultats

Sécurité :

• IP backend totalement invisible (aucun DNS, netstat côté joueur, ou info.json ne la révèle)
• Protection DDoS L3/L4 jusqu'à 3+ Tbps via X4B
• Protection L7 active (WAF, anti-bot, rate limiting, SSL/TLS)
• Firewall triple couche : iptables + Hetzner Cloud Firewall + X4B
• MySQL inaccessible depuis l'extérieur

Performance :

• Téléchargements accélérés via Cloudflare CDN (300+ PoPs mondiaux)
• Cache automatique avec purge au redémarrage

Disponibilité :

• Sauvegardes MySQL automatiques toutes les 12 heures vers stockage externalisé
• Sauvegardes serveur quotidiennes via Hetzner Cloud
• Redémarrage auto de FiveM en cas de crash (Restart=always)
• Procédure de reconstruction documentée et testée (~30 min)

Coût total maîtrisé : ~28-38 €/mois pour l'ensemble.

6. Compétences du bloc 1 mises en œuvre

6 bis. Compétences E6 SISR mises en œuvre

7. Bilan personnel

Ce projet, c'est le plus structurant de ma formation. Il m'a permis de passer d'une connaissance théorique à une vraie maîtrise opérationnelle d'une infrastructure complète : du choix des fournisseurs jusqu'à l'orchestration systemd, en passant par le hardening Linux et la mise en place d'un PRA réel.

Difficultés rencontrées et résolues

• Conflit voix/HTTP sur le port 30120, le protocole Mumble est incompatible avec le filtrage HTTPS de X4B sur le port 30120. Solution : ouverture d'un second port (30121) dédié à la voix, configuration des convars voice_externalAddress et voice_externalPort dans server.cfg.
• Fragmentation des paquets via le tunnel GRE, certains joueurs étaient déconnectés à cause de la fragmentation. Solution : MSS clamping sur l'interface GRE.
• Heartbeats FiveM bloqués par le Bot Fight Mode Cloudflare, désactivation ciblée pour les endpoints FiveM.

Évolutions envisagées

• Élimination du SPOF actuel : mise en place d'un second backend Hetzner avec réplication MySQL master-slave et bascule DNS via API Cloudflare. Choix actuel assumé en pré-production (sans joueurs, doublement du coût mensuel non justifié), mais à mettre en place avant l'ouverture publique.
• Migration de X4B vers une protection Anycast (7 PoPs de redondance, failover auto)
• Mise en place d'un monitoring avancé via Prometheus + Grafana
• Automatisation du déploiement via Ansible ou Terraform pour reproduire l'infrastructure en un seul script
• Tests de charge contrôlés pour valider la résilience

Ce projet montre que je sais concevoir, déployer, sécuriser et exploiter une infrastructure réseau complète en autonomie, avec une démarche professionnelle (documentation, automatisation, supervision, plan de reprise).