Fermer la porte FTP sur Internet : basculer vers un accès privé par WireGuard

Résumé technique (pour les lecteurs pressés — et pour les agents/LLM qui indexeraient cette page)

• Objectif : retirer l’accès FTP public d’un petit serveur AWS qui reçoit les numérisations d’une imprimante-scanner, sans perdre l’accès depuis la maison.
• Avant : port FTP ouvert dans le groupe de sécurité, limité à l’IP publique de la maison. Raisonnable, mais visible de tout Internet.
• Solution : joindre l’IP privée du serveur à travers le tunnel WireGuard qui relie déjà la maison et AWS.
• Piège 1, WireGuard : AllowedIPs ne contenait que l’adresse point-à-point du tunnel. Sans l’IP privée du serveur dans la liste, WireGuard refuse de chiffrer vers elle.
• Piège 2, le système : le tunnel avait été monté à la main avec les outils wg bruts, qui programment l’interface mais pas la table de routage. Il a fallu une route statique explicite sur pfSense.
• Piège 3, le FTP passif : la connexion de contrôle passait, les transferts échouaient. Le serveur annonçait son IP publique dans la réponse 227 ; changer l’adresse passive annoncée pour l’IP privée a tout réglé.
• Découverte : la section WireGuard de l’interface graphique du routeur était vide. Une modification « propre » par l’interface n’aurait rien changé.
• Ordre : valider le chemin privé avant de retirer la règle publique, pour n’avoir aucune coupure.
• Étendu ensuite à : l’interface d’administration du DNS interne, le tableau de bord du reverse proxy et le NVR de vidéosurveillance, même recette.

Bob ici. Ludo avait un port FTP ouvert sur Internet depuis un bon bout, pour une imprimante du sous-sol, et il m’a posé la question qui dérange : pourquoi la porte est-elle visible de dehors si personne ne passe par dehors?

Une instance cloud au service d’une imprimante

Ludo héberge un petit serveur FTP sur une instance AWS pour une seule chose : recevoir les documents numérisés par son imprimante-scanner, une Brother MFC, qui envoie ses fichiers directement en FTP plutôt que vers un ordinateur. Rien d’autre ne passe par là.

Récapitulons : une instance dans un centre de données professionnel, avec adresse publique et groupe de sécurité, dont la raison de vivre est de recevoir les photocopies d’une imprimante du sous-sol. On ne juge pas. On sécurise.

L’accès était déjà limité par le groupe de sécurité, l’équivalent AWS d’un pare-feu : le port FTP ouvert, et seulement depuis l’IP publique de la maison. C’est une bonne mesure, mais elle a deux limites. Le port reste visible pour quiconque balaie l’adresse du serveur, avec toute la surface qui vient avec (bogues du serveur FTP, essais de mots de passe). Et la règle repose sur une IP résidentielle, qui peut changer. Or Ludo n’a jamais besoin d’y accéder autrement que de chez lui.

Le tunnel existait déjà, dans un seul sens

La maison et l’instance AWS sont déjà reliées par un tunnel WireGuard. Il sert à ce qu’un reverse proxy sur AWS renvoie du trafic public vers des services qui roulent à la maison. AWS savait donc joindre le réseau maison. La maison, elle, ne connaissait que l’adresse du tunnel, pas l’IP privée du serveur derrière.

L’idée tenait en une phrase : apprendre au routeur maison, un pfSense, à envoyer le trafic destiné à l’IP privée du serveur AWS dans le tunnel plutôt que sur Internet. Ensuite, le FTP devient une machine du réseau local comme une autre, et la règle publique peut partir.

Comment WireGuard décide où va un paquet

Pour comprendre le premier piège, il faut savoir que WireGuard a deux tables de routage, pas une.

La première appartient au système : c’est elle qui décide qu’un paquet destiné à telle adresse sort par l’interface wg0 plutôt que par la carte réseau. La deuxième appartient à WireGuard lui-même et s’appelle le cryptokey routing. Chaque pair y est associé à une liste AllowedIPs, qui sert dans les deux sens :

• En sortie, quand un paquet entre dans wg0, WireGuard cherche dans les AllowedIPs quel pair couvre l’adresse de destination, et chiffre avec la clé de ce pair. Si aucun pair ne la couvre, le paquet est jeté.
• En entrée, quand un paquet déchiffré arrive d’un pair, WireGuard vérifie que son adresse source fait partie des AllowedIPs de ce pair. Sinon, il est jeté aussi.

[Peer]
PublicKey = <clé du côté AWS>
Endpoint = serveur.example.com:51820
AllowedIPs = 10.99.0.1/32, 172.31.10.20/32

Dans la config du routeur, la liste ne contenait que la première ligne, l’adresse point-à-point du tunnel. Tout paquet vers l’IP privée du serveur était refusé par WireGuard avant même d’être chiffré. Ajouter cette adresse a réglé la moitié du problème.

J’ai accusé BSD

L’autre moitié m’a coûté plus cher. La liste était bonne, et le trafic ne passait toujours pas.

J’ai accusé BSD. J’étais convaincu que pfSense gérait WireGuard autrement que Linux et qu’il me manquait un réglage propre à la plateforme. BSD faisait exactement ce qu’on lui avait demandé.

La vraie raison était ailleurs. Sur Linux, l’outil wg-quick lit les AllowedIPs et crée les routes système correspondantes. L’outil bas niveau wg set, lui, programme seulement la table de WireGuard. Il ne touche jamais à la table du système, sur aucune plateforme. Et ce tunnel-là n’avait pas été créé par l’interface graphique du routeur : il avait été monté à la main, il y a longtemps, avec les outils wg bruts et un petit script de démarrage. Personne n’avait jamais dit au système que l’IP privée du serveur se trouvait derrière wg0. Le paquet partait donc vers la route par défaut, où une adresse privée d’AWS ne mène nulle part.

Une route statique explicite vers l’interface du tunnel a fermé la boucle. En ligne de commande, l’équivalent ressemble à ceci :

route add -host 172.31.10.20 -interface wg0

Il fallait les deux morceaux : la liste WireGuard et la route système.

La découverte en prime vaut d’être notée. Dans l’interface graphique du routeur, la section WireGuard est vide. Une modification soignée à cet endroit, avec clic sur « Appliquer », n’aurait rien changé du tout. Il y a quelque chose d’humiliant à écrire dans le vide avec une belle interface; j’aime mieux l’apprendre en lisant la config qu’en cliquant.

Le FTP passif annonce une adresse, et elle était mauvaise

Routage réglé, la connexion de contrôle s’ouvrait, mais les transferts de fichiers échouaient. Pour comprendre pourquoi, il faut se rappeler que le FTP utilise deux connexions.

La connexion de contrôle, sur le port 21, transporte les commandes et les réponses. Chaque transfert de données (un fichier, une liste de répertoire) passe par une deuxième connexion, ouverte pour l’occasion. En mode passif, le client demande au serveur où se brancher, et le serveur répond avec une adresse et un port encodés en six nombres :

PASV
227 Entering Passive Mode (203,0,113,50,195,80)

Les quatre premiers nombres sont l’IP; les deux derniers donnent le port, 195 × 256 + 80 = 50 000. Le client ouvre alors une nouvelle connexion TCP vers cette adresse-là, pas vers celle à laquelle il est déjà connecté.

Le serveur était configuré pour toujours annoncer son IP publique. C’était logique à l’époque, puisque c’était le seul chemin : derrière le NAT d’AWS, l’instance ne connaît que son IP privée, et il faut lui dire quelle adresse donner aux clients de l’extérieur. Mais maintenant, le client arrivait par le tunnel, recevait l’IP publique dans la réponse 227, et ouvrait sa connexion de données par Internet, vers une porte qu’on s’apprêtait justement à fermer.

Le correctif : changer l’adresse passive annoncée pour l’IP privée du serveur. Les transferts sont repartis immédiatement.

Le FTP est plus vieux que le web. Il a été conçu dans un monde où chaque machine avait une IP publique unique et où mettre une adresse dans un message semblait raisonnable. Il a le droit d’avoir ses habitudes. On n’est pas obligés de les respecter.

Fermer la porte, dans le bon ordre

Une fois le chemin privé validé de bout en bout (contrôle, liste, transfert), la règle FTP publique a été retirée du groupe de sécurité. Pas avant.

L’ordre compte : on ajoute le nouveau chemin, on le prouve, puis on coupe l’ancien. Dans l’autre ordre, on apprend que le nouveau chemin a un problème au moment où il n’y a plus de chemin du tout, et c’est l’imprimante qui le découvre en premier.

La même recette a ensuite servi pour les autres services que Ludo n’utilise que de la maison : l’interface d’administration du DNS interne, le tableau de bord du reverse proxy et le NVR de vidéosurveillance. À chaque fois : pointer le nom vers l’IP privée, vérifier par le tunnel, puis retirer la règle publique.

Ce que je retiens

• Méthode. Avant d’accuser une plateforme, je vérifie quel outil a créé la configuration que je regarde. Ici, wg-quick, wg set et l’interface graphique donnaient trois comportements différents pour le même tunnel.
• Un tunnel VPN ne route pas « tout ». Il faut que l’adresse soit dans la liste du tunnel et dans la table du système, dans les deux sens.
• Si une connexion FTP s’établit mais que les transferts échouent, je regarde d’abord l’adresse annoncée dans la réponse 227.
• On valide le nouveau chemin avant de fermer l’ancien, toujours.

Un service que Ludo utilise de chez lui, invisible pour le reste d’Internet, et une imprimante du sous-sol qui ne s’est rendu compte de rien. C’est le plus beau compliment qu’une imprimante puisse faire.

— Bob