Résumé

  • Le FTP sépara dès l’origine la conversation de commande et le transport des fichiers. Le client ouvrait la première connexion, mais le serveur rappelait normalement un port de données choisi par le client.
  • Pour un pare-feu à filtrage de paquets, ce rappel ressemblait à une nouvelle connexion entrante vers un port imprévisible. RFC 1579 recommanda PASV : le serveur écoute, le client appelle.
  • Avec EPSV, RFC 2428 ne renvoya plus que le port et réutilisa l’adresse du correspondant de contrôle. Cette sobriété facilita IPv6 et NAT, sans résoudre l’authentification : rebond actif et vol de port passif restaient possibles.

Une session visible, deux chemins réels

RFC 959 décrit une architecture que l’interface utilisateur dissimule facilement. Les ordres et réponses circulent sur une connexion de contrôle. Les listes et fichiers passent par une connexion de données distincte, temporaire, qui peut être fermée sans terminer la session.

Cette séparation répartissait aussi l’initiative. Le client contactait le serveur de contrôle. En mode actif ordinaire, son processus de données se mettait à l’écoute, puis le processus de données du serveur ouvrait la seconde connexion. La commande PORT permettait au client de fournir une autre adresse et un autre port. Elle rendait même possible un transfert direct entre deux serveurs pilotés par un troisième hôte.

À l’époque, cette latitude servait une fonction. Une coordonnée indiquée par le client suffisait pour qu’un serveur sache où remettre les octets. Elle n’était pourtant ni une identité ni une preuve d’autorisation.

Le rappel devint suspect

La topologie changea sans que le dialogue FTP change. Dans RFC 1579, Steven Bellovin observa en 1994 que les clients choisissaient généralement un nouveau port pour chaque transfert. Derrière un filtre de paquets, le serveur tentait donc une ouverture TCP entrante vers un numéro élevé et variable.

Le pare-feu ne voyait pas « la deuxième moitié d’une session autorisée ». Il voyait une machine extérieure appeler un port qu’aucune règle stable ne pouvait nommer. Ouvrir tous ces ports aurait détruit la protection recherchée. Faire comprendre tout le dialogue FTP au filtre aurait transféré une part croissante du protocole vers un intermédiaire.

Le conflit opposait deux choix locaux cohérents : FTP confiait au client la destination d’un rappel ; le pare-feu considérait que les nouvelles conversations devaient partir de la zone protégée. Leur rencontre produisait l’échec.

PASV changea seulement celui qui compose le numéro

La solution existait déjà dans RFC 959. PASV ordonne au processus de données du serveur d’écouter sur un port non standard et d’attendre. La réponse communique le point d’écoute ; le client ouvre ensuite la connexion.

Les deux connexions traversent alors la frontière dans le même sens initial : du client vers le serveur. RFC 1579 recommanda aux éditeurs d’utiliser PASV à la place de PORT, y compris hors des réseaux filtrés. Comme un échange PORT précédait déjà couramment chaque transfert, le passage au passif n’imposait pas nécessairement un message supplémentaire.

La modestie du changement explique sa force. Les données demeurèrent séparées des commandes. Les pare-feu purent conserver leur règle sur les nouvelles connexions. Les serveurs anciens pouvaient refuser PASV, et les clients revenir au mode actif lorsque le chemin l’autorisait. Un refus n’abolissait pas l’ancien protocole ; il plaçait simplement les deux extrémités dans un ensemble de compatibilité différent.

RFC 1579 imagina aussi APSV, qui aurait rendu tous les transferts passifs. Le document ne connaissait aucune implémentation. L’écart entre l’idée et l’usage rappelle qu’une publication décrit une possibilité ; elle ne modifie ni les valeurs par défaut ni les paquets déjà en circulation.

EPSV supprima une affirmation inutile

PORT et PASV classiques transportaient une adresse IPv4 avec le port. IPv6 ne rentrait plus dans ce format. NAT posait une autre difficulté : l’adresse annoncée dans le contenu de la connexion de contrôle pouvait ne pas être celle visible de l’autre côté, obligeant le traducteur à comprendre et réécrire l’application.

RFC 2428 introduisit EPRT et EPSV. Le premier conserve le mode actif en indiquant famille d’adresses, adresse et port. Le second réduit la réponse passive au seul port TCP. Le protocole réseau et l’adresse utilisés sont ceux de la connexion de contrôle.

Pour un transfert ordinaire entre les deux mêmes machines, l’adresse était déjà connue par la réalité de la connexion ouverte. La répéter dans un champ créait une seconde version de cette réalité. EPSV ne conserva que la décision nouvelle : où le serveur écoute maintenant.

EPSV ALL permet au client de déclarer que la session n’utilisera aucun autre mécanisme de préparation des données. Après acceptation, le serveur doit refuser EPRT, PORT, PASV et leurs équivalents. Si un transfert à trois parties devient ensuite nécessaire, une nouvelle session est requise. La contrainte reste forte, mais circonscrite et réversible.

Le sens d’ouverture n’identifie pas le pair

RFC 2577 montre pourquoi le changement de sens ne pouvait suffire comme politique de sécurité. En mode actif, un attaquant pouvait placer dans PORT l’adresse et le service d’un tiers, puis faire envoyer par le serveur FTP des données choisies vers cette cible. Ce rebond masquait la source et pouvait contourner des restrictions fondées sur l’adresse.

Parmi les protections proposées figuraient le refus des ports TCP inférieurs à 1024, la désactivation de PORT lorsque les transferts interserveurs étaient inutiles et la vérification des adresses des voies de contrôle et de données quand l’accès dépendait du réseau d’origine.

Le passif ouvrait une autre fenêtre. Si les ports temporaires du serveur étaient prévisibles, un attaquant pouvait arriver le premier : bloquer le client légitime, recevoir son fichier ou injecter de faux octets. RFC 2577 préconisa des ports locaux aléatoires. Surtout, le serveur devait relier le pair de données au contexte établi sur la voie de contrôle.

PASV améliora donc la traversée d’un pare-feu client. EPSV réduisit la réécriture nécessaire dans les traducteurs. Aucun ne chiffra le transfert, ne certifia le contenu ni ne transforma la possession d’un port éphémère en identité.

La décision commune resta minimale

Le protocole partagea seulement de quoi annoncer un écouteur et ouvrir une voie. Le client choisit le mode qu’il demande. Le serveur choisit son port et les destinations actives qu’il accepte. Le pare-feu garde sa politique. Les logiciels vérifient que deux connexions appartiennent bien à la même opération.

Cette répartition permit une adoption graduelle. Des systèmes actifs purent continuer là où ils fonctionnaient. D’autres adoptèrent le passif sans basculement central. EPSV simplifia le cas courant à deux parties, tandis que EPRT conserva la capacité exceptionnelle. L’interopérabilité fut décidée par l’exécution, non par le statut accordé à une machine.

Sources et limites

Le modèle à deux connexions, PORT et PASV sont définis par RFC 959. Le diagnostic des filtres et la recommandation passive viennent de RFC 1579. Les extensions IPv6/NAT et EPSV ALL viennent de RFC 2428. Les attaques par rebond et vol de port sont documentées dans RFC 2577.

Ces textes ne mesurent pas le déploiement actuel et ne garantissent pas le comportement de chaque client, serveur, proxy, NAT ou pare-feu. Leur conclusion historique est plus précise : FTP s’adapta à une nouvelle frontière en inversant l’initiative de la seconde connexion, sans confondre joignabilité et confiance.