Résumé

  • Le FTP de 1985 séparait la conversation de commande du canal de données : un client pouvait ainsi organiser un transfert direct entre deux serveurs et indiquer un autre port avec PORT.
  • En 1999, RFC 2577 expliquait comment cette adresse librement choisie pouvait envoyer les données du serveur vers un service étranger à l'opération.

Un commissionnaire transporte une caisse entre deux entrepôts. Le commanditaire lui évite un détour par sa propre maison : gain de temps, surtout si le chemin jusqu'à cette maison est lent. Puis le commanditaire écrit lui-même l'adresse de livraison. Tout fonctionne tant qu'il indique le second entrepôt. La difficulté commence lorsqu'il inscrit la porte d'un service qui n'a jamais consenti à participer au déménagement.

Le RFC 959 d'octobre 1985 séparait déjà les commandes FTP du transport du fichier. Un client pouvait piloter deux sessions de commande avec deux serveurs, demander à l'un d'attendre une connexion de données et indiquer à l'autre, grâce à PORT, où se connecter. Les deux serveurs échangeaient alors le fichier sans le faire transiter par le client. Le texte évoquait même un hôte tiers ou une imprimante en ligne. À l'époque des liaisons lentes, cette liberté avait un intérêt très concret.

Le pouvoir était concentré dans le choix de l'adresse. PORT ne disait pas seulement que le client était prêt. Il désignait l'hôte et le port auxquels le serveur ouvrirait sa prochaine connexion de données. Dans un transfert par procuration légitime, l'hôte désigné était l'autre serveur FTP. Si le serveur obéissait à toute adresse fournie par le client, le même mécanisme pouvait l'envoyer chez une tierce machine. Pour cette machine, la connexion venait du serveur FTP; celui qui avait rempli le bon de livraison restait sur le canal de commande.

En février 1994, le RFC 1579 de Steve Bellovin examina une autre gêne de la même architecture : les pare-feu. En FTP actif, le serveur rappelle un port du client, souvent difficile à laisser entrer à travers un filtre. Bellovin conseillait aux logiciels clients d'utiliser PASV, qui fait attendre le serveur et laisse le client ouvrir la connexion sortante. Il mentionnait une proposition APSV, sans mise en œuvre connue de lui à cette date. Le sens de la connexion était devenu une décision visible, avec des conséquences pour l'administrateur de chaque côté.

Le réseau changeait aussi de format d'adresse. Le RFC 2428 de septembre 1998 introduisit EPRT et EPSV pour IPv6 et les traducteurs d'adresses. EPRT portait la famille d'adresses, l'adresse réseau et le port TCP du point de données. EPSV ALL annonçait qu'une session resterait limitée aux échanges entre deux parties; pour revenir à un transfert à trois, il fallait ouvrir une autre session. La syntaxe était nouvelle. La question de savoir à qui le serveur devait accepter d'envoyer des données, elle, était ancienne.

Le RFC 2577 de mai 1999, consacré à la sécurité FTP, mit des mots sur le détournement : l'attaque par rebond. Un client pouvait placer l'adresse et le port d'un autre service dans PORT, puis faire expédier des octets par le serveur FTP. Le document donne l'exemple d'un fichier contenant des commandes SMTP : le serveur FTP pourrait contacter le service de courrier d'une troisième machine et y transmettre ce contenu. Le client n'aurait pas besoin de se connecter lui-même à cette machine. Le relais de fichier devenait un intermédiaire commode pour emprunter une autre position sur le réseau.

Les remèdes avaient chacun leur prix. Le RFC suggérait de refuser les ports TCP inférieurs à 1024, avec la réponse 504 à une telle commande PORT. Cela protégeait une classe de services connus; les services installés plus haut demeuraient accessibles. Des permissions de fichier pouvaient empêcher un client de déposer des commandes puis de les envoyer ailleurs. Désactiver PORT supprimait la voie de transfert à trois, au prix de cette fonction utile. Les auteurs estimaient que PASV suffisait pour la plupart des transferts courants. L'arbitrage final appartenait au gestionnaire du serveur.

Ce parcours raconte une petite histoire de logistique devenue politique d'accès. FTP avait rendu le transport souple en séparant l'ordre et le camion. Les pare-feu, IPv6 et les services voisins ont rendu la destination moins innocente qu'elle n'en avait l'air. Le chauffeur pouvait toujours suivre les instructions du client; l'entreprise devait enfin décider quelles adresses avaient le droit de figurer sur son bon de route.