sv:serveur_ftp

Voir cette page sous forme de diaporama.

Serveur FTP

Cours Si5 - mardi 10 avril 2012

Le protocole FTP (File Transfer Protocol) est, comme son nom l'indique, un protocole de transfert de fichier.

Tous les systèmes d'exploitation réseau proposent un moyen de transférer des fichiers sur le réseau d'une machine à l'autre. Mais il s'agit généralement d'une solution propriétaire. Sous Windows par exemple le voisinage réseau utilise le protocole propriétaire SMB (Server Message Block), lui même s'appuyant sur NetBIOS (NETwork Basic Input-Output System)

FTP est un protocole ouvert qui peut être exploité sur tout système disposant d'une pile IP. Il devient donc possible de réaliser des transferts, sans se préoccuper du système d'exploitation de chacune des machines.

Contrairement à ce qu'il peut paraître, FTP est un protocole très complexe, capable de beaucoup plus de choses qu'un simple téléchargement depuis un lien sur une page web. Les clients FTP fournis avec les navigateurs sont souvent minimalistes et n'exploitent qu'une infime partie des possibilités de FTP.

Ce protocole ancien date de 1971 (décrit dans le RFC141), mis au point par le MIT (Massachussetts Institute of Technology). De nombreux RFC ont ensuite apporté des améliorations, les plus innovantes datent de juillet 1973. Le protocole FTP est actuellement défini par le RFC 959, en français ici.

Il s'appuie sur TELNET et comme lui souffre de nombreuses lacunes, en particulier au niveau de la sécurité : le mot de passe circule en clair sur le réseau. Si l'on souhaite effectuer des transferts sécurisés, il est recommandé d'utiliser SSH et SCP avec lesquels les communications sont cryptées ou SFTP (Secure FTP : FTP sur une couche sécurisée SSL)

FTP peut fonctionner en IPV4 et IPV6.

Le protocole FTP définit la façon selon laquelle des données doivent être transférées sur un réseau TCP/IP.

Le protocole FTP a pour objectifs de :

  • permettre un partage de fichiers entre machines distantes
  • permettre une indépendance aux systèmes de fichiers des machines clientes et serveur
  • permettre de transférer des données de manière efficace

Le protocole FTP s'inscrit dans un modèle client-serveur, c'est-à-dire qu'une machine envoie des ordres (le client) et que l'autre attend des requêtes pour effectuer des actions (le serveur). La plupart des navigateurs Web (Internet Explorer, FireFox, Konqueror, Opera, …) font office de client FTP.

Lors d'une connexion FTP, deux canaux de transmission sont habituellement utilisés :

  • Un canal pour les commandes (port 21, canal de contrôle FTP-Control)
  • Un canal pour les données (port 20 FTP-Data)

Ainsi, le client comme le serveur possèdent deux processus permettant de gérer ces deux types d'information :

  • le DTP (Data Transfer Process) est le processus chargé d'établir la connexion et de gérer le canal de données. Le DTP côté serveur est appelé SERVER-DTP, le DTP côté client est appelé USER-DTP
  • le PI (Protocol Interpreter) est l'interpréteur de protocole permettant de commander le DTP à l'aide des commandes reçues sur le canal de contrôle. Il est différent sur le client et sur le serveur :
    • Le SERVER-PI est chargé d'écouter les commandes provenant d'un USER-PI sur le canal de contrôle sur un port donné, d'établir la connexion pour le canal de contrôle, de recevoir sur celui-ci les commandes FTP de l'USER-PI, d'y répondre et de piloter le SERVER-DTP
    • Le USER-PI est chargé d'établir la connexion avec le serveur FTP, d'envoyer les commandes FTP, de recevoir les réponses du SERVER-PI et de contrôler le USER-DTP si besoin

Lors de la connexion d'un client FTP à un serveur FTP, le USER-PI initie la connexion au serveur selon le protocole Telnet. Le client envoie des commandes FTP au serveur, ce dernier les interprète, pilote son DTP, puis renvoie une réponse standard. Lorsque la connexion est établie, le serveur-PI donne le port sur lequel les données seront envoyées au Client DTP. Le client DTP écoute alors sur le port spécifié les données en provenance du serveur.

Il est important de remarquer que, les ports de contrôle et de données étant des canaux séparés, il est possible d'envoyer les commandes à partir d'une machine et de recevoir les données sur une autre.

Ainsi, il est par exemple possible de transférer des données entre deux serveurs FTP en passant par un client pour envoyer les instructions de contrôle et en transférant les informations entre deux processus serveurs connectés sur le bon port.

Dans cette configuration, le protocole impose que les canaux de contrôle restent ouverts pendant tout le transfert de données. Ainsi un serveur peut arrêter une transmission si le canal de contrôle est coupé lors de la transmission.

Le protocole FTP peut fonctionner selon deux modes

dans ce cas, après la connexion initiale qu'il a négociée avec le serveur FTP via le canal de contrôle, le client propose un port pour l'envoi des données. C'est alors le serveur FTP qui initie la connexion pour l'envoi des données sur ce port, autrement dit celui-ci agit comme un client TCP alors que le client FTP va agir comme un serveur TCP, c'est à dire qu'il va rester à l'écoute du port proposé. Cette particularité est due au mode actif. Le client FTP est actif, parce qu'ici, ce sera lui le serveur (au sens TCP).

Attention : Ce mode de fonctionnement pose des problèmes d'accès pour les serveurs situées derrière des pare-feux ou faisant de la NAT (Network Address Translation)

ici, le client demande au serveur de choisir un port aléatoire sur lequel ce dernier se mettra à l'écoute en attente de la connexion de données. Le serveur communique au client le port qu'il a choisi pour le transfert des données. Dans ce cas, le serveur n'initie aucune connexion. C'est le client FTP qui ouvre une connexion TCP sur le port que lui a indiqué le serveur, à la suite de la commande PASV.

Dans le cas de clients FTP sur un intranet voulant consulter un serveur FTP sur internet et devant traverser un pare-feu, le mode FTP passif permettra de n'avoir que des flux sortants vers internet alors qu'avec du FTP actif, on aurait le flux de données qui serait entrant sur le réseau interne …

Le mode passif est souvent « recommandé », uniquement parce qu'il fonctionne plus facilement derrière un routeur NAT. En réalité, les serveurs FTP préfèrent le mode actif qui est pour eux moins consommateur de ressources car en effet si le mode passif simplifie la vie pour le passage des filtres de paquets, il alourdit la charge des serveurs FTP. Chaque fois que ce sera possible, surtout si nous travaillons sur des « petits » serveurs FTP , utilisons plutôt le mode actif.

C'est la deuxième chose qu'il faut savoir paramétrer sur son client FTP, parce qu'en principe c'est lui qui décide du type des fichiers transférés au travers de l'envoi de la commande TYPE au serveur FTP.

Le transfert peut s’effectuer selon deux modes : binaire ou ASCII. Si l'on peut transférer n'importe quoi en mode binaire sans trop de risques, il n'en va pas de même si l'on essaye de transférer en mode ASCII un fichier qui n'est pas du texte …

le code ASCII (American Standard Code for Information Interchange - traduisez « Code Americain Standard pour l'Echange d'Informations ») de base représente les caractères sur 7 bits (c'est-à-dire 128 caractères possibles, de 0 à 127). Pour FTP, les caractères ASCII sont définis comme la moitié de l'ensemble donné par un codage à huit bits (le bit de poids fort est toujours à 0). Attention donc aux problèmes de corruption lors de transferts de fichiers non ASCII !

Par défaut, le client peut être paramétré pour faire une détection automatique, en fonction de l'extension du fichier à transférer (pour télécharger un fichier .txt, il choisira automatiquement le mode ASCII).

La plupart des navigateurs et clients FTP fonctionnent par défaut en mode binaire.

Vous pouvez forcer un mode. Bien entendu, si vous forcez le mode ASCII, les fichiers non ASCII arriveront corrompus. Il n'y a pas ici de mécanisme de type MIME pour faire de l'encodage base 64 par exemple.

Si vous devez forcer un mode, forcez le mode binaire, qui fonctionnera avec tout type de fichier, mais pas forcément de manière optimale.

Le FTP anonyme permet de mettre des fichiers à la disposition de tous les utilisateurs. Il ne nécessite pas d'authentification particulière, d'où son nom, et n'autorise l'accès qu'à une partie bien spécifique du système de fichiers. Dans le cas d'un FTP anonyme, le serveur utilise une fonctionnalité appelée « environnement prison » ou chroot qui emprisonne l'utilisateur dans une arborescence spécifique.

En FTP anonyme, la racine du serveur FTP est le répertoire de base de l'utilisateur ftp, (habituellement /var/ftp sous Linux et c:\inetpub\ftproot sous Windows). La connection à un serveur FTP anonyme se fait avec le nom d'utilisateur anonymous et le mot de passe peut être n'importe quelle adresse électronique (pas forcément valide mais contenant au moins le caractère @). Tous les clients FTP et les navigateurs sont déjà préconfigurés pour le FTP anonyme.

Le FTP non anonyme permet à un utilisateur de se retrouver dans son répertoire de base. Lors de l'accès en FTP d'un utilisateur, celui-ci peut « remonter » dans l'arborescence, sortir de son répertoire personnel, et copier des fichiers présents dans /etc ou /var . On voit aisément les problèmes de sécurité que cela pose …

Toutes les communications effectuées sur le canal de contrôle suivent les recommandations du protocole Telnet. Ainsi les commandes FTP sont des chaînes de caractères Telnet (en code NVT-ASCII) terminées par le code de fin de ligne Telnet, c'est-à-dire la séquence <CR>+<LF> (Carriage Return : retour chariot, suivi du caractère Line Feed, notée <CRLF>.

Si la commande FTP admet un paramètre, celui-ci est séparé de la commande par un espace (<SP>).

Les commandes FTP permettent de préciser :

  • Le port utilisé
  • Le mode de transfert des données
  • La structure des données
  • La nature de l'action à effectuer (Retrieve, List, Store, …)

On distingue trois types de commandes FTP :

  • Les commandes de contrôle d'accès
  • Les commandes du paramétrage de transfert
  • Les commandes de service FTP
Commande Description
USER Chaîne de caractères permettant d'identifier l'utilisateur. Cela est nécessaire pour établir une communication sur le canal de données
PASS Chaîne de caractères spécifiant le mot de passe de l'utilisateur. Cette commande fait suite à la commande USER.
ACCT Account : Chaîne de caractères représentant le compte de l'utilisateur. Cette commande n'est généralement pas nécessaire. Lors de la réponse à l'acceptation du mot de passe, si la réponse est 230 cette phase n'est pas nécessaire, si la réponse est 332, elle l'est
CWD Change Working Directory : cette commande permet de changer le répertoire courant. Cette commande nécessite le chemin d'accès au répertoire à atteindre comme argument
CDUP Change to Parent Directory : cette commande permet de remonter au répertoire parent. Elle a été introduite pour remédier aux problèmes de nommage de répertoire parent selon les système (généralement “..”)
SMNT Structure Mount : monter un volume sous un système de fichier différent sans changer de contexte pour la session.
REIN Reinitialize
QUIT Commande permettant de terminer la session en cours. Le serveur attend de finir le transfert en cours le cas échéant, puis de fournir une réponse avant de fermer la connexion
Commande Description
PORT Chaîne de caractères permettant de préciser le numéro de port à utiliser
PASV Commande permettant d'indiquer au serveur DTP de se mettre en attente d'une connexion sur un port spécifique choisi aléatoirement parmi les ports disponibles. La réponse à cette commande est l'adresse IP de la machine et le port.
TYPE Cette commande permet de préciser le type de format dans lequel les données seront envoyées
STRU Caractère Telnet précisant la structure du fichier (F pour File, R pour Record, P pour Page)
MODE Caractère Telnet précisant le mode de transfert des données (S pour Stream, B pour Block, C pour Compressed)
Commande Description
RETR RETRieve : demande au serveur DTP une copie du fichier dont le chemin d'accès est passé en paramètre.
STOR STORe : demande au serveur DTP d'accepter les données envoyées sur le canal de données et de les stocker dans le fichier portant le nom passé en paramètre. Si le fichier n'existe pas, le serveur le crée, sinon il l'écrase
STOU Cette commande est identique à la précédente, si ce n'est qu'elle demande au serveur de créer un fichier dont le nom est unique. Le nom du fichier est retourné dans la réponse
APPE append : les données envoyées sont concaténées dans le fichier portant le nom passé en paramètre s'il existe déjà, dans le cas contraire il est créé
ALLO ALLOcate : demande au serveur de prévoir un espace de stockage suffisant pour contenir le fichier dont le nom est passé en argument.
REST RESTart : permet de reprendre un transfert là où il s'était arrêté. Pour cela cette commande envoie en paramètre le marqueur représentant la position dans le fichier à laquelle le transfert avait été interrompu. Cette commande doit être immédiatement suivie d'une commande de transfert.
RNFR ReName FRom : permet de renommer un fichier. Elle indique en paramètre le nom du fichier à renommer et doit être immédiatement suivie de la commande RNTO
RNTO ReName TO : permet de renommer un fichier. Elle indique en paramètre le nom du fichier à renommer et doit être immédiatement précédée de la commande RNFR
ABOR ABORt : indique au serveur DTP d'abandonner tous les transferts associés à la commande précédente. Si aucune connexion de données n'est ouverte, le serveur DTP ne fait rien, sinon il la ferme. Le canal de contrôle reste par contre ouvert.
DELE DELEte : permet de supprimer le fichier dont le nom est passé en paramètre. Cette commande est irrémédiable, seule une confirmation au niveau du client peut être faite.
RMD ReMove Directory : permet de supprimer un répertoire. Elle indique en paramètre le nom du répertoire à supprimer
MKD MaKe Directory : permet de créer un répertoire. Elle indique en paramètre le nom du répertoire à créer
PWD Print Working Directory : permet de renvoyer le chemin complet du répertoire courant
LIST Cette commande permet de renvoyer la liste des fichiers et répertoires présents dans le répertoire courant. Cette liste est envoyée sur le DTP passif. Il est possible de passer en paramètre de cette commande un nom de répertoire, le serveur DTP enverra la liste des fichiers dans le répertoire passé en paramètre
NLST Name liste : permet d'envoyer la liste des fichiers et répertoires dans le répertoire courant
SITE Cette commande (site parameters) permet au serveur de proposer des services spécifiques, non définis dans le protocole FTP
SYST SYSTem : permet d'envoyer des informations sur le serveur distant
STAT status : permet d'émettre l'état du serveur, par exemple pour connaître la progression d'un transfert en cours. Cette commande accepte en argument un chemin d'accès, elle retourne alors les mêmes informations que LIST mais sur le canal de contrôle
HELP Cette commande permet de connaître l'ensemble des commandes comprises par le serveur. Les informations sont retournées sur le canal de contrôle
NOOP NO OPerations : sert uniquement à obtenir une commande OK du serveur. Elle peut servir uniquement pour ne pas être déconnecté après un temps d'inactivité trop élevé

Les réponses FTP permettent d'assurer la synchronisation entre client et serveur FTP. Ainsi à chaque commande envoyée par le client, le serveur effectuera éventuellement une action et renverra systématiquement une réponse.

Les réponses sont constituées d'un code à 3 chiffres indiquant la façon suivant laquelle la commande envoyée par le client a été traitée. Toutefois, ce code à 3 chiffres étant difficilement lisible par un humain, il est accompagné d'un texte (chaîne de caractères Telnet séparée du code numérique par un espace).

Les codes de réponse sont constitués de 3 chiffres dont voici les significations :

  • Le premier chiffre indique le statut de la réponse (succès ou échec)
  • Le second chiffre indique ce à quoi la réponse fait référence
  • Le troisième chiffre donne une signification plus spécifique (relative à chaque deuxième chiffre)
  • sv/serveur_ftp.txt
  • Dernière modification : 2012/04/09 15:33
  • de 127.0.0.1