Un tunnel qui compose vers l'extérieur, pour n'avoir aucun port entrant

La forme normale d'un déploiement auto-hébergé, c'est : le serveur écoute sur 80 et 443, un pare-feu autorise ces deux-là, et tout le reste est fermé. C'est correct, et ça laisse quand même deux ports face à tout internet, plus SSH si tu ne fais pas attention, plus ce qu'un conteneur mal configuré publie accidentellement sur 0.0.0.0.

L'installation que je fais tourner à la place : l'hôte de production ne publie rien sur le réseau de l'hôte. Chaque conteneur parle à ses voisins sur des réseaux Docker privés uniquement. Un client tunnel tourne comme un de ces conteneurs, établit une unique connexion TLS sortante vers le fournisseur de périphérie, et tout le trafic entrant arrive par cette connexion déjà ouverte. Les règles entrantes du pare-feu sont, vraiment, « refuser tout ».

Pourquoi ça vaut la dépendance

• Il n'y a aucun port à scanner. Un attaquant qui énumère l'IP de l'hôte ne trouve rien à l'écoute. L'IP d'origine elle-même peut rester effectivement secrète.
• Un conteneur qui bind accidentellement 0.0.0.0:9229 — un débogueur, un serveur de dev égaré — n'est pas soudainement exposé, parce que l'hôte n'est pas joignable peu importe ce qu'un conteneur publie.
• La périphérie absorbe les attaques volumétriques avant qu'elles n'atteignent une connexion que la petite VM doit servir.

Fais tourner le client tunnel en deux répliques sur les mêmes identifiants — un unique processus tunnel est un point de défaillance unique pour tout le site, et un second est quasi gratuit.

Ce que ça coûte

Une dépendance dure à un seul fournisseur pour la joignabilité, et une surface de config — les règles d'ingress qui mappent les noms d'hôte aux services internes — qui vit dans leur tableau de bord, pas dans ton dépôt. Garde un miroir versionné de cette config même si ce n'est pas la source de vérité, pour qu'un tableau de bord perdu soit une reconstruction et pas une panne que tu débogues à l'aveugle. Et garde le dev et la production sur des tunnels séparés — ne réutilise jamais un jeu d'identifiants entre environnements.

Le principe général : le port le plus sûr est celui qui n'a jamais été ouvert. Si la joignabilité entrante peut être une connexion sortante à la place, c'est une catégorie de surface d'attaque supprimée plutôt que défendue.