Étude de cas · Auto-hébergement

Infrastructure auto-hébergée sous TLS

Exposer un service sur Internet depuis chez soi, c'est publier son adresse IP résidentielle et ouvrir un port sur son propre réseau. J'ai transformé un ancien PC en serveur pour 60 utilisateurs — et le vrai sujet n'a jamais été le service, mais tout ce qui l'entoure.

Rôle: Administration système et réseau — seul
Durée: 2025 — plusieurs mois d'exploitation
Utilisateurs: Communauté de 60 joueurs
Stack: Linux · SSH · TLS / Let's Encrypt · reverse proxy · Cloudflare · TCPShield
Enjeu: Exposer un service sans exposer le réseau domestique

Le problème

Héberger un service de jeu chez un prestataire coûte un abonnement mensuel et n'apprend rien. Je voulais le faire moi-même, sur une machine que je contrôle entièrement. Le service en lui-même est trivial à lancer : un processus, un port.

La difficulté est ailleurs. Ouvrir un port depuis une connexion résidentielle signifie publier son adresse IP personnelle à chaque joueur qui se connecte. Cette adresse identifie le foyer, elle est stable dans le temps, et elle devient une cible : un déni de service ne coupe pas seulement le jeu, il coupe la connexion Internet de la maison.

Modèle de menace

Avant de configurer quoi que ce soit, j'ai listé ce que je cherchais réellement à empêcher. Sans cette étape, on empile des outils sans savoir contre quoi ils protègent.

Divulgation de l'IP résidentielle — un joueur lit l'adresse du serveur dans son client. Conséquence : géolocalisation approximative du domicile, et cible permanente.
Déni de service volumétrique — saturer la liaison. Conséquence : toute la maison perd Internet, pas seulement le service.
Accès non autorisé à l'administration — SSH et la console web exposés. Conséquence : prise de contrôle de la machine, donc pivot vers le réseau local.
Interception des identifiants d'administration — console web en clair. Conséquence : vol de session sur un réseau non maîtrisé.
Pivot vers le réseau domestique — le serveur compromis sert de tremplin vers les autres machines du foyer.

L'architecture

Le principe directeur : aucun client ne parle jamais directement à la machine. Le trafic de jeu et le trafic d'administration empruntent deux chemins distincts, et l'adresse réelle n'apparaît dans aucun des deux.

Deux chemins distincts, une seule règle : l'adresse réelle n'est jamais exposée au client.

Décisions techniques

Relais TCP en amont, plutôt qu'une redirection de port directe

Port forwarding vers la box

Une redirection simple fonctionne, et publie l'adresse du domicile. Faire transiter le trafic par un relais spécialisé résout deux problèmes d'un coup : les clients ne connaissent que l'adresse du relais, et le trafic d'attaque volumétrique est absorbé en amont, avant d'atteindre la liaison résidentielle.

Le coût est une latence supplémentaire de quelques millisecondes. Pour un service de jeu, c'est perceptible en théorie et négligeable en pratique ; comparé à la perte de la connexion du foyer, l'arbitrage n'est pas discutable.

Console d'administration derrière un proxy inverse avec TLS

Accès direct en HTTP

La console d'administration ne sert que du HTTP en clair, et n'est pas conçue pour être exposée. Je ne l'ai pas exposée : elle n'écoute qu'en local, et un proxy inverse assure seul la terminaison TLS avec un certificat Let's Encrypt renouvelé automatiquement.

L'application n'a pas eu à être modifiée, et le chiffrement est géré à un seul endroit, par un composant dont c'est le métier. Le renouvellement automatique compte autant que le certificat lui-même : un certificat qu'on renouvelle à la main est un certificat qui expirera.

SSH par clé, authentification par mot de passe désactivée

Mot de passe fort

Tout port SSH atteignable subit des tentatives automatisées en continu. Un mot de passe fort résiste, mais reste devinable en théorie et vulnérable à la réutilisation. Désactiver complètement l'authentification par mot de passe supprime la classe d'attaque au lieu de la rendre difficile — et transforme le bruit de fond des tentatives en non-événement.

Difficultés rencontrées

L'IP fuyait malgré le relais

Mettre un relais devant le service ne suffit pas si l'adresse réelle reste accessible autrement. Un enregistrement DNS oublié, un sous-domaine ancien, un service secondaire répondant sur le même hôte : chacun annule la protection, et il suffit d'une seule fuite.

J'ai dû auditer tous les enregistrements DNS du domaine et vérifier qu'aucun ne pointait vers l'adresse d'origine, puis m'assurer que le service refusait les connexions n'arrivant pas par le relais. Sans ce second point, un attaquant ayant retrouvé l'adresse par un autre moyen contourne simplement le filtre.

Le service ne voyait plus que l'adresse du relais

Conséquence logique du relais : toutes les connexions semblent provenir de la même adresse. Les outils de modération par adresse deviennent inopérants, et les journaux perdent leur valeur. Il a fallu configurer le service pour lire l'adresse réelle transmise par le relais dans l'en-tête prévu à cet effet — en n'acceptant cet en-tête que du relais, sans quoi n'importe qui pourrait usurper une adresse en la déclarant lui-même.

Un ancien PC n'est pas un serveur

Redémarrages après coupure de courant, disque grand public, absence de supervision : les modes de défaillance d'une machine de bureau ne sont pas ceux d'un serveur. Les services ont été passés en démarrage automatique avec redémarrage en cas d'échec, ce qui couvre la majorité des incidents — mais la disponibilité reste celle d'une machine domestique, et c'est une limite qu'aucune configuration ne supprime.

Résultats

joueurs sur l'infrastructure

exposition de l'IP résidentielle

100 %

du trafic d'administration chiffré

auto

renouvellement des certificats

Le service a fonctionné plusieurs mois sans incident de sécurité ni interruption liée à une attaque. C'est en cherchant à protéger ma propre connexion que j'ai compris la différence entre installer un service et l'exploiter — une leçon qui vaut pour tout ce que je développe depuis.

Session SSH sur le serveur : connexion par clé publique et état des services système. — Accès d'administration : authentification par clé, mot de passe désactivé.

Ce que je referais autrement

Aucune supervision. Je découvrais les pannes parce qu'un joueur le signalait. Une sonde externe vérifiant la disponibilité et alertant par message aurait coûté une heure de mise en place — c'est le manque le plus évident.

Aucune sauvegarde hors site. Les données vivaient sur un seul disque, dans un seul boîtier, sur un seul site. Un incendie ou une panne de disque effaçait des mois de progression collective. Je n'ai pas eu à l'apprendre à mes dépens, mais c'était de la chance, pas de la conception.

Pas de segmentation réseau. Le serveur était sur le même réseau que les machines personnelles du foyer. Une compromission lui donnait un accès direct au reste. Un VLAN dédié, ou simplement un réseau invité, aurait limité le rayon d'action.