ADR-004 : Limiter l’exposition réseau des services
Statut
Section titled “Statut”Accepté
- Date : 01/07/2026
- Auteur : Corentin Talour
Cet ADR a été rédigé a posteriori afin de documenter une décision
Contexte et problème
Section titled “Contexte et problème”La plateforme utilise plusieurs services qui écoutent sur des ports différents. Certains sont destinés aux utilisateurs, tandis que d’autres servent uniquement aux communications internes entre les applications.
L’exposition directe de tous ces ports augmenterait la surface d’attaque du VPS et permettrait de contourner Caddy et les protections associées.
Il est donc nécessaire de déterminer quels ports peuvent être accessibles depuis Internet et comment les communications internes doivent être organisées.
Options considérées
Section titled “Options considérées”Option 1 : Exposer directement chaque application
Section titled “Option 1 : Exposer directement chaque application”Chaque application publie son propre port sur toutes les interfaces réseau du VPS.
Cette solution facilite certains tests, mais augmente la surface d’attaque et permet de contourner le reverse proxy.
Option 2 : Filtrer uniquement avec UFW
Section titled “Option 2 : Filtrer uniquement avec UFW”Les applications peuvent écouter sur toutes les interfaces, tandis qu’UFW bloque les ports qui ne doivent pas être accessibles.
Cette solution centralise les règles réseau, mais une erreur de pare-feu peut exposer accidentellement un service. Les règles créées par Docker peuvent également interagir avec celles d’UFW.
Option 3 : Combiner le pare-feu avec une écoute locale (choisi)
Section titled “Option 3 : Combiner le pare-feu avec une écoute locale (choisi)”Les applications destinées à Caddy publient leurs ports uniquement sur 127.0.0.1. Les services internes communiquent à travers les réseaux Docker sans publier leurs ports sur l’hôte.
UFW complète cette isolation en refusant par défaut les connexions entrantes.
Décision
Section titled “Décision”Seuls les ports suivants sont accessibles publiquement :
| Port | Protocole | Usage |
|---|---|---|
22 |
TCP | Administration du serveur avec SSH |
80 |
TCP | HTTP et validation des certificats TLS |
443 |
TCP | Accès HTTPS aux applications |
Les règles suivantes sont appliquées :
- UFW refuse par défaut les connexions entrantes
- le trafic sortant est autorisé
- le port SSH utilise une limitation du débit des connexions
- Caddy est l’unique point d’entrée des applications web
- les applications transmises par Caddy écoutent sur
127.0.0.1 - les bases de données et services internes restent dans les réseaux Docker
- leurs ports ne sont pas publiés sur l’interface publique du VPS
Une application ne doit pas publier un port sur 0.0.0.0 sans justification
et sans nouvelle décision explicite.
Conséquences
Section titled “Conséquences”Positives
Section titled “Positives”- la surface d’attaque publique est réduite
- les services internes ne sont pas directement accessibles depuis Internet
- les utilisateurs passent obligatoirement par Caddy
- les bases de données ne sont pas exposées publiquement
- les certificats TLS et les domaines sont gérés de manière centralisée
- une erreur applicative expose moins facilement un port interne
Négatives
Section titled “Négatives”- le diagnostic d’une application peut nécessiter une connexion SSH ou un tunnel local
- les fichiers Docker Compose doivent être vérifiés attentivement
- une mauvaise adresse d’écoute peut rendre une application inaccessible à Caddy
- les règles réseau de Docker peuvent interagir avec celles d’UFW
- l’ajout d’un nouveau port public nécessite une modification contrôlée du pare-feu