Plus avant
[ Accueil ] [ Pourquoi FTP ? ] [ Les bases de FTP ] [ Plus avant ] [ Cadeau bonus ]
Ici, nous allons voir quelques points importants :
- Le mode passif,
- le transfert de fichiers contenant autre chose que du texte,
- un transfert en upload.
Le mode Passif
La première chose à faire, lorsque l'on prend en main un client FTP, c'est de trouver à quel endroit on peut lui expliquer qu'il doit fonctionner en mode actif, ou passif. Continuons avec Filezilla. Dans le menu "Edition/paramètres" :
La rubrique "Connexion/Paramètres Pare feu" permet, entre autres, de sélectionner le mode passif ou non. Nous allons sélectionner le mode passif et voir ce que ça donne. Rassurez-vous, nous n'allons voir que ce qui change vraiment par rapport au mode actif :
No. Time Source Destination Protocol Info ...
L'ouverture de session FTP est faite, la connexion de commandes est établie, le client envoie la première commande "PWD"
20 10.588511 192.168.0.10 194.2.0.36 FTP Request: PWD 21 10.609876 194.2.0.36 192.168.0.10 FTP Response: 257 "/" is current directory.
Jusqu'ici, tout était pareil, mais voyons la suite :
22 10.613105 192.168.0.10 194.2.0.36 FTP Request: PASV
Cette nouvelle commande indique au serveur FTP que nous souhaitons fonctionner en mode passif.
23 10.661077 194.2.0.36 192.168.0.10 FTP Response: 227 Entering Passive Mode (194,2,0,36,17,77).
Le serveur accepte (227 veut dire : "Passage en mode passif"), et indique un numéro de port, ici 17 x 256 77 = 4429
24 10.663545 192.168.0.10 194.2.0.36 FTP Request: TYPE A 25 10.693712 194.2.0.36 192.168.0.10 FTP Response: 200 Type set to A. 26 10.697611 192.168.0.10 194.2.0.36 FTP Request: LIST 27 10.698306 192.168.0.10 194.2.0.36 TCP 1870 > 4429 [SYN]
Voyez ici comment la connexion TCP destinée à supporter le canal de données est créée. Ce n'est plus le serveur FTP qui, depuis son port 20 initie une connexion vers le client FTP, mais le client FTP qui ouvre une connexion TCP sur le port que lui a indiqué le serveur, à la suite de la commande PASV.
28 10.731631 194.2.0.36 192.168.0.10 TCP ftp > 1869 [ACK]
29 10.736716 194.2.0.36 192.168.0.10 TCP 4429 > 1870 [SYN, ACK]
30 10.736751 192.168.0.10 194.2.0.36 TCP 1870 > 4429 [ACK]
31 10.757437 194.2.0.36 192.168.0.10 FTP Response: 150 Opening ASCII mode data
connection for file list
32 10.761018 194.2.0.36 192.168.0.10 FTP-DATA FTP Data: 75 bytes
...
Le reste ne présente pas de nouveautés particulières.
Que pouvons-nous en conclure ?
Dans le mode passif, le client FTP est toujours client TCP. A charge pour le serveur FTP d'ouvrir de nouveaux ports sur lesquels il sera encore serveur TCP, pour le support des canaux de données. Le client FTP n'est jamais serveur TCP. Ca simplifie la vie pour le passage des filtres de paquets, mais ça alourdit la charge des serveurs FTP.
Chaque fois que ce sera possible, surtout si vous travaillez sur des "petits" serveurs FTP , utilisez plutôt le mode actif.
Le transfert non ASCII
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. Nous avons bien vu que c'était lui qui envoyait la commande TYPE. Toujours sur Filezilla :
Ce client FTP est vraiment très bien fait... Toujours dans le menu "Edition/paramètres", allez dans "Paramètres de transfert/ASCII/Binaire" et voyez. Par défaut, notre client est paramétré pour faire une détection automatique, en fonction de l'extension du fichier. Comme nous avons téléchargé un fichier txt, il a choisi automatiquement le mode ASCII. 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.
Quelles différences ?
Juste un petit morceau de sniff :
No. Time Source Destination Protocol Info ... 418 57.591410 192.168.0.10 194.2.0.36 FTP Request: TYPE I
Le type demandé est maintenant I et non plus A
419 57.612530 194.2.0.36 192.168.0.10 FTP Response: 200 Type set to I.
420 57.615147 192.168.0.10 194.2.0.36 FTP Request: PASV
421 57.635511 194.2.0.36 192.168.0.10 FTP Response: 227 Entering Passive Mode (194,2,0,36,18,136).
422 57.640090 192.168.0.10 194.2.0.36 FTP Request: RETR rfc765.txt
423 57.640783 192.168.0.10 194.2.0.36 TCP 1111 > 4744 [SYN]
424 57.679211 194.2.0.36 192.168.0.10 TCP 4744 > 1111 [SYN, ACK]
425 57.679269 192.168.0.10 194.2.0.36 TCP 1111 > 4744 [ACK]
426 57.684695 194.2.0.36 192.168.0.10 TCP ftp > 1105 [ACK]
427 57.699374 194.2.0.36 192.168.0.10 FTP Response: 150 Opening BINARY mode data
connection for rfc765.txt (146641 bytes).
Le serveur répond qu'il ouvre le fichier en mode binaire et non plus ASCII
428 57.722806 194.2.0.36 192.168.0.10 FTP-DATA FTP Data: 1412 bytes 429 57.724012 194.2.0.36 192.168.0.10 FTP-DATA FTP Data: 1412 bytes ...
Quels résultats ?
Juste pour voir, ouvrons les deux copies téléchargées avec Wordpad :
La copie téléchargée au format ASCII :
Et celle téléchargée au format binaire :
C'est peut-être un peu moins lisible...
Mais que s'est-il donc passé ?
Rien de bien grave, rassurez-vous. Le document initial est au format UNIX et le document local est passé au format Microsoft. La différence est infime, mais perturbante.
En ASCII, il existe deux caractères non imprimables nommés CR (Carriage Return, retour chariot , de code 0D) et LF (Line Feed, saut de ligne, de code 0A).
Dans un fichier texte UNIX, les retours à la ligne sont signalés par un LF, alors que chez Microsoft, ils le sont par un couple CR LF.
Lors du transfert en mode ASCII, la conversion est effectuée, alors que lors du transfert binaire, rien n'est modifié dans le fichier, ce qui est heureux.
Rassurez-vous, si Notepad ne sait pas interpréter correctement le code LF tout seul, Wordpad, lui, sait le faire, et vous retrouverez votre fichier bien lisible, même s'il est téléchargé en mode binaire.
La RFC 959 explique d'ailleurs la chose au paragraphe 3.1.1.1
Où le serveur engueule le client
J'ai hésité à développer un transfert "upload", cette opération se passant de façon très similaire à un "download". Finalement, je me suis dit que ce serait l'occasion de voir quelques subtilités supplémentaires :
- En utilisant un autre client FTP, ici, ce sera le client gFTP sous GNU/Linux
- En utilisant un autre serveur FTP, ici, le serveur perso-ftp.wanadoo.fr.
En effet, chaque client FTP a ses petites habitudes et chaque serveur aussi...
Upload en mode actif d'un fichier binaire depuis gFTP vers perso-ftp.wanadoo.fr
Une fois de plus, nous allons étudier dans le détail cet échange, ça ne fait pas de mal de répéter les choses.
No. Time Source Destination Protocol Info 93 1.620013 192.168.0.254 193.252.18.14 TCP 32781 > ftp [SYN] 94 1.650006 193.252.18.14 192.168.0.254 TCP ftp > 32781 [SYN, ACK] 95 1.650162 192.168.0.254 193.252.18.14 TCP 32781 > ftp [ACK]
Ouverture du canal de contrôle
96 2.228519 193.252.18.14 192.168.0.254 FTP Response: 220 pwp-ftp2 FTP server
(@(#)Version : 3-2-2 2002/08/21) ready.
97 2.228698 192.168.0.254 193.252.18.14 TCP 32781 > ftp [ACK]
98 2.229021 192.168.0.254 193.252.18.14 FTP Request: USER xxxxxxxx
99 2.256639 193.252.18.14 192.168.0.254 TCP ftp > 32781 [ACK]
100 2.261983 193.252.18.14 192.168.0.254 FTP Response: 331 PagePerso login ok, send your passwd.
101 2.262205 192.168.0.254 193.252.18.14 FTP Request: PASS xxxxxx
102 2.388503 193.252.18.14 192.168.0.254 TCP ftp > 32781 [ACK]
103 2.388952 193.252.18.14 192.168.0.254 FTP Response: 230 User xxxxxx logged in.
Access restrictions apply.
Identification du client
104 2.389150 192.168.0.254 193.252.18.14 FTP Request: TYPE I 105 2.414035 193.252.18.14 192.168.0.254 FTP Response: 200 Type set to I.
gFTP, quand on lui dit : "Mode binaire", il fait "mode binaire", même pour la récupération de la liste du répertoire. Bête et discipliné, quoi...
106 2.414241 192.168.0.254 193.252.18.14 FTP Request: PWD 107 2.433222 193.252.18.14 192.168.0.254 FTP Response: 257 "/pub" is current directory. 108 2.438940 192.168.0.254 193.252.18.14 FTP Request: PORT 192,168,0,254,128,14 109 2.462881 193.252.18.14 192.168.0.254 FTP Response: 200 PORT command successful. 110 2.463200 192.168.0.254 193.252.18.14 FTP Request: LIST -aL 111 2.582733 193.252.18.14 192.168.0.254 TCP ftp > 32781 [ACK]
Mais il demande des détails. Les options "a" et "L" permettent d'obtenir les noms commençant par un point (entrées cachées) ainsi que la taille et les attributs de chaque entrée du répertoire.
112 2.757014 193.252.18.14 192.168.0.254 TCP ftp-data > 32782 [SYN] 113 2.757157 192.168.0.254 193.252.18.14 TCP 32782 > ftp-data [SYN, ACK] 114 2.774846 193.252.18.14 192.168.0.254 TCP ftp-data > 32782 [ACK]
Ouverture du canal de données.
115 2.775365 193.252.18.14 192.168.0.254 FTP Response: 150 Opening BINARY mode data connection
for /bin/ls.
116 2.808833 193.252.18.14 192.168.0.254 FTP-DATA FTP Data: 520 bytes
117 2.808916 193.252.18.14 192.168.0.254 TCP ftp-data > 32782 [FIN, ACK]
118 2.808983 192.168.0.254 193.252.18.14 TCP 32782 > ftp-data [ACK]
119 2.809821 192.168.0.254 193.252.18.14 TCP 32782 > ftp-data [FIN, ACK]
120 2.822139 192.168.0.254 193.252.18.14 TCP 32781 > ftp [ACK]
121 2.835875 193.252.18.14 192.168.0.254 TCP ftp-data > 32782 [ACK]
Le canal de données est fermé d'un commun accord.
122 2.844263 193.252.18.14 192.168.0.254 FTP Response: 226-Transfer complete. 123 2.844383 192.168.0.254 193.252.18.14 TCP 32781 > ftp [ACK] 126 6.738405 192.168.0.254 193.252.18.14 FTP Request: PORT 192,168,0,254,128,15 127 6.760458 193.252.18.14 192.168.0.254 FTP Response: 200 PORT command successful. 128 6.760606 192.168.0.254 193.252.18.14 TCP 32781 > ftp [ACK] 129 6.760844 192.168.0.254 193.252.18.14 FTP Request: STOR /pub/ie6_proxy_1.gif
Le client va envoyer son fichier.
130 6.886677 193.252.18.14 192.168.0.254 TCP ftp > 32781 [ACK] 131 6.923111 193.252.18.14 192.168.0.254 TCP ftp-data > 32783 [SYN] 132 6.923242 192.168.0.254 193.252.18.14 TCP 32783 > ftp-data [SYN, ACK] 133 6.947755 193.252.18.14 192.168.0.254 TCP ftp-data > 32783 [ACK]
Un nouveau canal de données est ouvert.
134 6.948206 193.252.18.14 192.168.0.254 FTP Response: 150 Opening BINARY mode data connection
for /pub/ie6_proxy_1.gif.
135 6.959283 192.168.0.254 193.252.18.14 FTP-DATA FTP Data: 1412 bytes
136 6.960470 192.168.0.254 193.252.18.14 FTP-DATA FTP Data: 1412 bytes
137 6.982307 192.168.0.254 193.252.18.14 TCP 32781 > ftp [ACK]
Et le transfert démarre.
138 6.986320 193.252.18.14 192.168.0.254 TCP ftp-data > 32783 [ACK] 139 6.987578 192.168.0.254 193.252.18.14 FTP-DATA FTP Data: 1412 bytes 140 6.988767 192.168.0.254 193.252.18.14 FTP-DATA FTP Data: 1412 bytes 141 6.999923 193.252.18.14 192.168.0.254 TCP ftp-data > 32783 [ACK] 142 7.001176 192.168.0.254 193.252.18.14 FTP-DATA FTP Data: 1412 bytes 143 7.002388 192.168.0.254 193.252.18.14 FTP-DATA FTP Data: 1412 bytes 144 7.123111 193.252.18.14 192.168.0.254 TCP ftp-data > 32783 [ACK] 145 7.124365 192.168.0.254 193.252.18.14 FTP-DATA FTP Data: 1412 bytes 146 7.125555 192.168.0.254 193.252.18.14 FTP-DATA FTP Data: 1412 bytes 147 7.126746 192.168.0.254 193.252.18.14 FTP-DATA FTP Data: 1412 bytes 148 7.314251 193.252.18.14 192.168.0.254 TCP ftp-data > 32783 [ACK] 149 7.315529 192.168.0.254 193.252.18.14 FTP-DATA FTP Data: 1412 bytes 150 7.315885 192.168.0.254 193.252.18.14 FTP-DATA FTP Data: 372 bytes 151 7.315950 192.168.0.254 193.252.18.14 TCP 32783 > ftp-data [FIN, ACK] 152 7.502913 193.252.18.14 192.168.0.254 TCP ftp-data > 32783 [ACK] 153 7.680958 193.252.18.14 192.168.0.254 TCP ftp-data > 32783 [ACK] 154 7.713910 193.252.18.14 192.168.0.254 TCP ftp-data > 32783 [ACK] 155 7.714014 193.252.18.14 192.168.0.254 FTP Response: 226 Transfer complete. 156 7.714093 193.252.18.14 192.168.0.254 TCP ftp-data > 32783 [FIN, ACK] 157 7.714166 192.168.0.254 193.252.18.14 TCP 32781 > ftp [ACK] 158 7.714232 192.168.0.254 193.252.18.14 TCP 32783 > ftp-data [ACK]
Le transfert est terminé, le canal de données est fermé.
159 7.714542 192.168.0.254 193.252.18.14 FTP Request: SITE CHMOD 744 /pub/ie6_proxy_1.gif 160 7.765540 193.252.18.14 192.168.0.254 FTP Response: 200 CHMOD command successful. 161 7.802347 192.168.0.254 193.252.18.14 TCP 32781 > ftp [ACK]
Le monde Unix...
Le client gFTP demande au serveur de changer les attributs du fichier. 744, ça veut dire en gros que le propriétaire a tous les droits et que les autres ne peuvent que lire.
162 8.334702 192.168.0.254 193.252.18.14 FTP Request: PORT 192,168,0,254,128,16
163 8.355047 193.252.18.14 192.168.0.254 FTP Response: 200 PORT command successful.
164 8.355196 192.168.0.254 193.252.18.14 TCP 32781 > ftp [ACK]
165 8.355366 192.168.0.254 193.252.18.14 FTP Request: LIST -aL
166 8.435637 193.252.18.14 192.168.0.254 TCP ftp-data > 32784 [SYN]
167 8.435767 192.168.0.254 193.252.18.14 TCP 32784 > ftp-data [SYN, ACK]
168 8.457199 193.252.18.14 192.168.0.254 TCP ftp-data > 32784 [ACK]
169 8.457363 193.252.18.14 192.168.0.254 FTP Response: 150 Opening BINARY mode data connection
for /bin/ls.
170 8.464111 193.252.18.14 192.168.0.254 FTP-DATA FTP Data: 591 bytes
171 8.464194 193.252.18.14 192.168.0.254 TCP ftp-data > 32784 [FIN, ACK]
172 8.464262 192.168.0.254 193.252.18.14 TCP 32784 > ftp-data [ACK]
173 8.465013 192.168.0.254 193.252.18.14 TCP 32784 > ftp-data [FIN, ACK]
174 8.492369 192.168.0.254 193.252.18.14 TCP 32781 > ftp [ACK]
175 8.494386 193.252.18.14 192.168.0.254 TCP ftp-data > 32784 [ACK]
176 8.511638 193.252.18.14 192.168.0.254 FTP Response: 226-Transfer complete.
Rien de bien nouveau, le client rafraîchit la liste des entrées du répertoire courant.
177 8.511763 192.168.0.254 193.252.18.14 TCP 32781 > ftp [ACK] 178 14.584417 192.168.0.254 193.252.18.14 TCP 32781 > ftp [FIN, ACK] 179 14.603193 193.252.18.14 192.168.0.254 TCP ftp > 32781 [ACK]
Le client ferme alors le canal de contrôle, sans autre forme de procès...
180 14.603616 193.252.18.14 192.168.0.254 FTP Response: 221 You could at least say goodbye.
Et se fait jeter par le serveur qui, bien poli, aurait aimé entendre une formule de politesse du genre "au revoir et merci"
181 14.603731 192.168.0.254 193.252.18.14 TCP 32781 > ftp [RST]
Mais le client répond en gros "va te faire f..." [RST] indiquant au serveur qu'il parle devant une porte fermée.
Finalement, le savoir vivre informatique est aussi mal distribué que le savoir vivre humain...
Ca y est ? Nous avons tout vu ?
Non. FTP sait encore faire d'autres choses que nous n'avons pas vues ici, mais nous avons pu observer l'essentiel :
- Le transfert binaire ou ASCII. C'est une notion qu'il faut connaître si l'on ne veut pas risquer de perdre beaucoup de temps. 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.
- Les modes Actif et Passif. La notion est elle aussi essentielle, surtout s'il y a un pare-feu à filtrage de paquets non configuré pour autoriser le mode actif, c'est à dire le mode où le client FTP se retrouve serveur TCP sur le canal de données.
- Nous avons vu avec suffisamment de précision le mécanisme des canaux de commandes et de données, en modes actif et passif, pour pouvoir configurer avec quelques espoir de réussite un firewall du genre GNU/Linux avec Netfilter.
Nous n'avons pas vu en revanche :
- Comment utiliser FTP pour faire de l'impression distante,
- comment utiliser FTP à travers un serveur PROXY ou un proxy SOCKS, mais ces problèmes ne sont pas spécifiquement du ressort de FTP et ne peuvent se rencontrer qu'en entreprise.
- Enfin, nous n'avons pas vu certains modes de transfert que FTP sait faire, relatifs à la compression des données et à la reprise en cas d'incident, mais pour utiliser ces possibilités, encore faut-il disposer d'un client qui sache les gérer.
- Finalement, nous n'avons pas fait non plus de transfert de fichier de serveur à serveur avec un client distant. Pour mener à bien cette tâche, il vous faudra :
- Un client FTP qui sache faire ce genre d'opérations, Sous Windows, je n'en ai trouvé qu'un : FlashFXP, qui est un shareware,
- des serveurs FTP qui acceptent ce genre d'opérations.
Comme la maison ne recule devant rien, vous trouverez tout de même en page suivante une illustration de ce type de transfert.
Si vous voulez en savoir d'avantage sur FTP, vous pourrez lire maintenant la RFC 959 (dont la traduction en français est disponible ici) avec quelques chances d'y comprendre quelque chose.