Les bases de FTP

Un client (utilisateur FTP) va se servir de ce protocole, pour faire du transfert de fichiers (upload ou download) sur un serveur FTP.

Il existe une multitude de logiciels clients en mode graphique pour réaliser ces opérations. Passons sur les fonctions FTP implémentées dans les navigateurs web (Internet Explorer, Mozilla…), qui ne sont pas toujours très pratiques.

Vous serez probablement surpris de constater le nombre impressionnant de clients FTP disponibles, le plus souvent en « shareware » (Windows oblige). Il en existe cependant au moins un sous licence GPL : Filezilla. En plus d'être sous licence GPL, ce logiciel est également localisé en français, ce qui ne gâte rien.

A noter également le module complémentaire de Firefox : FireFTP qui offre à ce navigateur de véritables fonctions de client FTP.

Nous avons gftp , naturellement sous licence GPL, mais également le même FileZilla porté sur GNU/Linux et aussi Mac OS X. Bien entendu, le module FireFTP de Firefox reste d'actualité.

Il existe enfin des utilitaires FTP en ligne de commande, aussi bien sous Windows que sous Linux. Il sont certainement moins conviviaux, mais pas forcément moins puissants. L'outil en ligne de commande lftp est sans doute le plus abouti. Les utilisateurs de MS Windows devront s'en passer.

Dans la suite, nous utiliserons donc le client Filezilla :

Les clients FTP graphiques ont tous plus ou moins la même présentation. Ici, nous nous sommes connectés au serveur mir1.ovh.net de façon anonyme. Nous aurons l'occasion de revenir sur ce mode de connexion.

La partie gauche représente l'arborescence locale et la partie droite, celle du serveur FTP.

Le client ouvre une session FTP sur un serveur. Il existe une grande quantité de serveurs FTP publics. Un serveur FTP requiert une identification du client. Il existe souvent un compte « anonyme », qui donne accès en lecture seule dans la partie publique du serveur, mais il existe également des parties privées où les clients disposant d'un compte peuvent accéder en écriture sur certains répertoires de l'arborescence. C'est le cas, par exemple, pour les mises à jour de pages web personnelles.

La première chose que l'on constate, c'est que, contrairement à d'autres protocoles comme HTTP, nous allons ici utiliser au moins deux canaux distincts :

• L'un pour l'échange des commandes du protocole,
• l'autre pour le transfert des données elle-mêmes. Il est possible d'ouvrir plusieurs canaux de données simultanément,si le serveur l'autorise, par exemple si l'on souhaite récupérer plusieurs fichiers sur un serveur.

Le client FTP (partie de droite), par l'intermédiaire de l'interface utilisateur, va cacher les diverses commandes du protocole FTP par des manipulations plus conviviales, en proposant à l'utilisateur une vision des choses similaire à un gestionnaire de fichiers. Avec des clics et des « glisser/déposer » l'utilisateur exploitera FTP sans en connaitre la multitude de commandes.

Un utilisateur pourra exploiter FTP pour transférer depuis son poste de travail des fichiers d'un serveur distant à un autre serveur distant, sans que les données ne transitent par sa machine, ce qui est fort intéressant si l'on travaille depuis une connexion à faible débit pour passer des données volumineuses d'une machine à une autre, ces dernières étant quant-à-elles connectées par des liens à haut débit. Cependant, cette opération ne sera possible que si les serveurs FTP l'acceptent (FXP), ce qui n'est pas souvent le cas, pour des raisons de sécurité et nous n'en parlerons pas d'avantage ici.

Le meilleur moyen pour comprendre FTP n'est probablement pas la lecture des RFC mais plutôt l'expérimentation, du moins dans un premier temps. Nous allons donc mettre en œuvre FTP, voir comment les choses se passent et vérifier seulement après que c'est bien conforme à ce qui est dit dans les Livres.

Les manipulations sont faites depuis un poste client connecté à un LAN, lui-même connecté à l'Internet par une passerelle NAT GNU/Linux. Un sniffeur est placé sur le poste client lui-même, il aurait pu l'être sur la passerelle.

Il faut bien prendre le problème par un bout pour le décortiquer, même si pour l'instant, nous ne savons rien ou pas grand chose de FTP. Nous sommes donc obligés de faire appel à un paramétrage du client, sans trop savoir pourquoi on va le faire comme ça. Nous y reviendrons par la suite.

Le protocole FTP supporte deux manières de fonctionner, à peine différentes, mais la différence est d'importance, surtout lorsque l'on doit traverser un pare-feu par filtrage de paquets. Ce sont les modes actif et passif.

Pour l'instant, contentons-nous de dire que si l'on doit passer un pare-feu, il vaut mieux utiliser le mode passif, car le mode actif risque de se solder rapidement par un échec. Ceci dit, le pare-feu utilisé ici est construit avec Iptables, qui sait parfaitement reconnaitre du FTP actif et le laisser passer sans encombre si nous lui en avons donné la consigne. Nous allons donc commencer par ce mode là.

Le résultat de la manipulation qui suit n'est plus tout jeune, les noms des hôtes et du fichier téléchargé ne sont plus d'actualité, mais le protocole, lui, n'a pas changé et l'exemple est toujours valide.

Nous avions créé une connexion au serveur ftp.oleane.fr, parcouru son arborescence, et téléchargé le fichier /pub/doc/rfc/rfc765.txt.

L'étude qui va suivre est assez longue, voire laborieuse. Munissez-vous de temps, de friandises et de boissons, parce que nous allons rester coincés ici pendant un petit moment…

Pour vous éviter de faire plusieurs aller-retours sur la page, j'ai essayé d'organiser cette étude de façon la plus linéaire possible, c'est ce qui rend ce paragraphe très long. Allons-y.

No. Time     Source        Destination  Protocol Info
  1 0.000000 192.168.0.10  194.2.0.36   TCP      1175 > ftp [SYN]
  2 0.022327 194.2.0.36    192.168.0.10 TCP      ftp  > 1175 [SYN, ACK]
  3 0.022356 192.168.0.10  194.2.0.36   TCP      1175 > ftp [ACK]

Établissement d'une connexion TCP entre le client (192.168.0.10:1175) et le serveur (192.2.0.36:21). Le port 21 est le port standard d'écoute des commandes FTP. Nous trouvons ici le classique dialogue [SYN], [SYN,ACK], [ACK]. Etait-il nécessaire de le signaler ? FTP s'appuie bien entendu sur un mode connecté (TCP).

Pour savoir que le port nommé ftp est bien le port 21, il suffit d'aller regarder dans le détail de la trame 1 par exemple :

Frame 1 (62 bytes on wire, 62 bytes captured)
    ...
    Transmission Control Protocol, Src Port: 1175 (1175), Dst Port: ftp (21)
    Source port: 1175 (1175)
    Destination port: ftp (21)
    ...

Mais passons à la suite…

  4 0.055680 194.2.0.36    192.168.0.10 FTP      Response: 220 ProFTPD 1.2.0pre10 Server (ProFTPD)
                                                           [ftp.oleane.net]

Le serveur entame le dialogue propre au protocole FTP en se présentant. Chaque réponse commence par un nombre, optionnellement suivi d'un commentaire. La réponse 220 signifie : « Service disponible pour nouvel utilisateur ».
Vous aurez l'occasion de constater dans la suite à quel point les systèmes informatiques savent être civilisés. Le serveur se présente, par la même occasion.

  5 0.057744 192.168.0.10  194.2.0.36   FTP      Request: USER anonymous

Le client se présente aussi en indiquant son nom. Comme nous avons fait un accès anonyme, nous utilisons le nom conventionnel anonymous. Nous n'aurons droit qu'à un accès en lecture. Si nous avions disposé d'un compte d'utilisateur, nous aurions un identifiant personnel (nom d'utilisateur et mot de passe) qui nous permettrait éventuellement de disposer d'un droit d'accès en écriture dans un répertoire de l'arborescence.

  6 0.078527 194.2.0.36    192.168.0.10 TCP      ftp > 1175 [ACK]
  7 0.081892 194.2.0.36    192.168.0.10 FTP      Response: 331 Anonymous login ok, send your complete
                                                           e-mail address as password.

Le serveur accepte les accès anonymes. Ce n'est pas une obligation, certains serveurs ne le font pas. En général, en accès anonyme, l'adresse e-mail du client utilisateur est employée comme mot de passe, mais tout ce qui a vaguement une forme d'adresse e-mail est généralement accepté.

  8 0.084076 192.168.0.10  194.2.0.36   FTP      Request: PASS anon@localhost

La preuve, Filezilla envoie un laconique anon@localhost et tout va fonctionner quand même…
PASS est une commande FTP, c'est l'abréviation de Password.

  9 0.108851 194.2.0.36    192.168.0.10 FTP      Response: 230-Welcome, archive user
                                                           anonymous@ca-marseille-51-107.abo.wanadoo.fr!

La preuve… La réponse 230 veut dire : « Session ouverte ». Notons tout de même que le serveur a ici effectué une requête « reverse DNS » sur notre adresse IP, d'où la réponse anonymous@ca-marseille-51-107.abo.wanadoo.fr.

 11 0.109313 192.168.0.10  194.2.0.36   TCP      1175 >  ftp [ACK]
 12 0.109914 194.2.0.36    192.168.0.10 FTP      Response: 230-The local time is:
                                                           Sat Jan 11 10:32:57 2003
 13 0.110341 194.2.0.36    192.168.0.10 FTP      Response: 230-
 14 0.110365 192.168.0.10  194.2.0.36   TCP      1175 > ftp [ACK]
 15 0.131452 194.2.0.36    192.168.0.10 FTP      Response: 230-For informations about
                                                           this archive service,
                                                           or to report problems,

Le serveur nous donne son heure locale, qui peut être utile si l'on devait signaler un problème à l'administrateur du service.

 16 0.141903 192.168.0.10  194.2.0.36   FTP      Request: PWD

Le client envoie la commande PWD qui signifie : « Print Working Directory »

 17 0.172747 194.2.0.36    192.168.0.10 FTP      Response: 257 "/" is current directory.

Nous sommes à la racine de l'arborescence du serveur FTP. Le code 257 signifie « Chemin créé ».

Nous avons initié une connexion FTP avec le serveur. Nous nous sommes identifié comme un utilisateur anonyme et nous nous retrouvons dans la racine de l'arborescence du serveur FTP.
Nous avons vu quelques commandes FTP : USER, PASS, PWD et quelques codes de réponse. Jusqu'ici, c'était relativement simple, nous n'avons transmis que des commandes et des réponses à ces commandes. Maintenant, ça va commencer à se compliquer, parce que nous allons faire aussi transiter des données.

 18 0.176308 192.168.0.10  194.2.0.36   FTP      Request: PORT 192,168,0,10,4,152

Première commande curieuse : PORT 192.168.0.10,4,152, qui nécessite quelques explications.

• PORT, c'est une commande. Le client signale qu'il voudrait utiliser un port particulier ;
• 192.168.0.10, l'adresse du client et notons bien que nous voyons ici une adresse IP privée, non routable sur l'internet,
• 4,152, c'est la notation d'un numéro de port, écrit à la mode des adresses IP, c'est à dire sous forme de deux octets, dont chaque octet est exprimé en valeur décimale. Dans la pratique, ceci veut dire que le port spécifié sera 4 x 256 + 152 = 1176

La suite va nous indiquer plus clairement à qui va servir ce port.

 19 0.198149 194.2.0.36    192.168.0.10 FTP      Response: 200 PORT command successful.

Le serveur répond qu'il est d'accord. 200 signifie : « Commande conclue ».

 20 0.200751 192.168.0.10  194.2.0.36   FTP      Request: TYPE A

La commande TYPE indique au serveur quel type de données sont attendues. Le type A signale que l'on attend du texte ASCII.

 21 0.223387 194.2.0.36    192.168.0.10 FTP      Response: 200 Type set to A.

Le serveur est toujours d'accord.

 22 0.225874 192.168.0.10  194.2.0.36   FTP      Request: LIST

La commande LIST qui signifie que le client attend la liste des objets présents dans le répertoire courant (l'équivalent de la commande DIR de MSDOS ou ls de UNIX).

Attention !!!
Ce qu'il va se passer maintenant réclame beaucoup d'attention. Rappelons-nous :

• Que nous sommes en mode Actif,
• Que le client a demandé l'usage du port 1176

23 0.247769 194.2.0.36    192.168.0.10 TCP      ftp-data > 1176 [SYN]
24 0.247826 192.168.0.10  194.2.0.36   TCP      1176 > ftp-data [SYN, ACK]
25 0.264940 194.2.0.36    192.168.0.10 TCP      ftp > 1175 [ACK]
26 0.267461 194.2.0.36    192.168.0.10 TCP      ftp-data > 1176 [ACK]

Le serveur FTP initie une nouvelle connexion FTP (trames 23,24 et 26). Mais vous avez bien vu, c'est le serveur qui initie la connexion, autrement dit, il agit comme un client TCP, et c'est le client FTP qui va agir comme un serveur TCP, c'est à dire qu'il va rester à l'écoute de son port 1176. Cette particularité est due au mode actif. Le client FTP est actif, parce qu'ici, ce sera lui le serveur (au sens TCP).

Mais comment… 192.168.0.10, c'est une adresse privée, comment le serveur FTP d'Oléane peut-il joindre une adresse privée, non routable par définition ?

Notre sniffeur se situe sur le poste client. Si nous l'avions placé sur le routeur NAT, nous aurions observé d'autres adresses, l'adresse publique du routeur à la place de 192.168.0.10. C'est sûrement un coup du Netfilter. Il est fort ce Netfilter…

Il est fort mais tout de même il faut l'aider. Netfilter sait faire du suivi de connexion, c'est-à-dire dans son jargon identifier des connexions RELATED (relatives à une connexion déjà existante). Il sait le faire avec de l'aide de modules spécifiques pour des protocoles où il est nécessaire d'analyser le dialogue au niveau de l'application.

Netfilter travaille normalement au niveau Internet (IP), des modules particuliers peuvent se charger automatiquement pour la gestion du transport (TCP/UDP) si le filtrage nécessite de s'intéresser aux ports utilisés. Quelques modules spéciaux peuvent permettre d'analyser le contenu au niveau Application, c'est ce qui nous intéresse ici avec les modules nf-conntrack-ftp et nf-nat-ftp, mais il faut charger explicitement ces modules « à la main » ou au moment de l'init. C'est ce qui a été fait sur le routeur NAT utilisé ici.

C'est le module nf-nat-ftp qui permet ici de remplacer à la volée l'adresse locale (privée) du client par celle publique de la passerelle, et d'effectuer l'opération inverse sur les réponses du serveur.

Si nous n'avons pas les moyens de disposer d'un tel outil sur le routeur NAT, le mode actif ne pourra fonctionner, nous devrons nous contenter du mode passif où le serveur FTP est aussi serveur sur les canaux de données.

A ce stade, nous avons deux connexions TCP ouvertes :

• 192.168.0.10:1175 → 194.2.0.36:21. Cette connexion sert à faire passer les commandes et les réponses à ces commandes, 194.2.0.36 est le serveur, au sens TCP, c'est lui qui écoute sur son port 21 ce que le client FTP lui raconte, c'est le canal de commande
• 194.2.0.36:20 → 192.168.0.10:1176. Cette connexion va servir à faire passer les données. Ici, la liste du répertoire racine du serveur FTP vers le client FTP, qui agit comme un serveur TCP. Ce sera le canal de données.

 27 0.299444 194.2.0.36    192.168.0.10 FTP      Response: 150 Opening ASCII mode data
                                                            connection for file list.

Le serveur FTP répond 150, c'est à dire : « Statut de fichier vérifié, ouverture de canal de données en cours ».

 28 0.303502 194.2.0.36    192.168.0.10 FTP-DATA FTP Data: 75 bytes
 29 0.305993 194.2.0.36    192.168.0.10 FTP-DATA FTP Data: 699 bytes
 30 0.306052 192.168.0.10  194.2.0.36   TCP      1176 > ftp-data [ACK]
 31 0.306101 194.2.0.36    192.168.0.10 FTP      Response: 226-Transfer complete.

Normalement, c'est bien le catalogue de la racine du serveur FTP qui a été envoyée vers le client FTP. Nous pouvons le vérifier en regardant par exemple les données contenues dans la trame 29. Ce n'est pas très lisible, mais c'est bien ça. Je vous demande de me croire sur parole, inutile de charger encore d'avantage cette page déjà lourde. :

La réponse 226 signifie : « Fermeture du canal de données. Service terminé ».

 32 0.306117 192.168.0.10  194.2.0.36   TCP      1175 > ftp [ACK]
 33 0.306470 194.2.0.36    192.168.0.10 FTP      Response: 226 Quotas off
 34 0.307484 192.168.0.10  194.2.0.36   TCP      1176 > ftp-data [FIN, ACK]
 35 0.338378 194.2.0.36    192.168.0.10 TCP      ftp-data > 1176 [ACK]

Comme c'était prévu, 192.168.0.10:1176 met fin à la connexion TCP qui a servi de support au canal de données. C'est le client FTP qui met fin à cette connexion.

 36 0.457543 192.168.0.10  194.2.0.36   TCP      1175 > ftp [ACK]
 37 2.447889 192.168.0.10  194.2.0.36   FTP      Request: CWD pub

Nous sommes de nouveau sur le canal de commandes et le client FTP demande à changer de répertoire. CWD voulant dire : « Change Working Directory ». Nous allons dans le répertoire pub. Ce qui va maintenant suivre va ressembler à ce que nous venons de voir. Je vous laisse la totalité des trames pour deux raisons :

• Nous permettre de vérifier que vous avez bien compris le mécanisme, parce que je ne vais pas tout répéter,
• permettre d'observer un détail qui n'est pas sans importance…

 38 2.471233 194.2.0.36    192.168.0.10 FTP      Response: 250 CWD command successful.
 39 2.473782 192.168.0.10  194.2.0.36   FTP      Request: PWD
 40 2.499085 194.2.0.36    192.168.0.10 FTP      Response: 257 "/pub" is current directory.
 41 2.502415 192.168.0.10  194.2.0.36   FTP      Request: PORT 192,168,0,10,4,153
 42 2.524624 194.2.0.36    192.168.0.10 FTP      Response: 200 PORT command successful.
 43 2.527863 192.168.0.10  194.2.0.36   FTP      Request: TYPE A
 44 2.549182 194.2.0.36    192.168.0.10 FTP      Response: 200 Type set to A.
 45 2.551642 192.168.0.10  194.2.0.36   FTP      Request: LIST
 46 2.572805 194.2.0.36    192.168.0.10 TCP      ftp-data > 1177 [SYN]
 47 2.572856 192.168.0.10  194.2.0.36   TCP      1177 > ftp-data [SYN, ACK]
 48 2.585185 194.2.0.36    192.168.0.10 TCP      ftp > 1175 [ACK]
 49 2.593535 194.2.0.36    192.168.0.10 TCP      ftp-data > 1177 [ACK]

Selon le même mécanisme que celui vu plus haut, un nouveau canal de données est ouvert, mais le client FTP utilise un nouveau port : 1177, cette fois-ci. C'est un détail qui a son importance…

En effet, dans le cas où nous avons beaucoup de fichiers à transférer, nous allons utiliser beaucoup de ports successivement. Pour calculer des firewalls qui ne sont pas « statefull », ceci ne simplifiera pas les choses.

 50 2.595535 194.2.0.36    192.168.0.10 FTP      Response: 150 Opening ASCII mode data
                                                           connection for file list.
 51 2.625058 194.2.0.36    192.168.0.10 FTP-DATA FTP Data: 59 bytes
 52 2.627332 194.2.0.36    192.168.0.10 FTP-DATA FTP Data: 718 bytes
 53 2.627375 192.168.0.10  194.2.0.36   TCP      1177 > ftp-data [ACK]
 54 2.629615 194.2.0.36    192.168.0.10 FTP      Response: 226-Transfer complete.
 55 2.629654 192.168.0.10  194.2.0.36   TCP      1175 > ftp [ACK]
 56 2.630203 194.2.0.36    192.168.0.10 FTP      Response: 226 Quotas off
 57 2.652599 194.2.0.36    192.168.0.10 FTP-DATA FTP Data: 1229 bytes
 58 2.652668 192.168.0.10  194.2.0.36   TCP      1177 > ftp-data [ACK]
 59 2.654073 192.168.0.10  194.2.0.36   TCP      1177 > ftp-data [FIN, ACK]
 60 2.700163 194.2.0.36    192.168.0.10 TCP      ftp-data > 1177 [ACK]

Bien, nous n'allons pas poursuivre plus longtemps le cheminement dans les sous répertoires, d'autant qu'à chaque niveau, le catalogue devient de plus en plus volumineux.

 87 11.063406   192.168.0.10          194.2.0.36            FTP      Request: CWD rfc
...
 95 11.177496   192.168.0.10          194.2.0.36            FTP      Request: LIST
...

Et un grand saut plus loin :

413 29.719734 192.168.0.10  194.2.0.36   FTP      Request: PWD
414 29.741101 194.2.0.36    192.168.0.10 FTP      Response: 257 "/pub/doc/rfc"
                                                            is current directory.

Nous arrivons enfin dans le bon répertoire…

415 29.912570 192.168.0.10  194.2.0.36   TCP      1180 >; ftp [ACK]
416 30.584219 192.168.0.10  194.2.0.36   FTP      Request: TYPE A
417 30.605939 194.2.0.36    192.168.0.10 FTP      Response: 200 Type set to A.
418 30.609380 192.168.0.10  194.2.0.36   FTP      Request: PORT 192,168,0,10,4,157
419 30.635498 194.2.0.36    192.168.0.10 FTP      Response: 200 PORT command successful.
420 30.639387 192.168.0.10  194.2.0.36   FTP      Request: RETR rfc765.txt
421 30.660814 194.2.0.36    192.168.0.10 TCP      ftp-data > 1181 [SYN]
422 30.660867 192.168.0.10  194.2.0.36   TCP      1181 > ftp-data [SYN, ACK]
423 30.676003 194.2.0.36    192.168.0.10 TCP      ftp > 1180 [ACK]
424 30.683263 194.2.0.36    192.168.0.10 TCP      ftp-data > 1181 [ACK]
425 30.684698 194.2.0.36    192.168.0.10 FTP      Response: 150 Opening ASCII mode data
                                                            connection for rfc765.txt (146641 bytes).
426 30.685450 194.2.0.36    192.168.0.10 FTP-DATA FTP Data: 2 bytes
427 30.687400 194.2.0.36    192.168.0.10 FTP-DATA FTP Data: 716 bytes

Nous ouvrons encore un nouveau canal de données, nous en sommes maintenant au port 1181, données de type A toujours (ASCII) et utilisons la commande RETR (Retrieve) pour transférer le fichier rfc765.txt depuis le serveur FTP vers le client FTP.

Certains lecteurs à l'œil acéré auront remarqué que le port utilisé par le client FTP sur le canal de commande a changé depuis le début de la session. Pour une raison parasite, il y a eu une re-connexion au serveur à la fin de la transmission du catalogue de /pub/doc/rfc, re-connexion qui a entrainé l'ouverture d'un nouveau canal de commande, sans que le précédent ne soit fermé.

428 30.687446 192.168.0.10  194.2.0.36   TCP      1181 > ftp-data [ACK]
429 30.710881 194.2.0.36    192.168.0.10 FTP-DATA FTP Data: 1400 bytes
430 30.712372 194.2.0.36    192.168.0.10 FTP-DATA FTP Data: 1400 bytes
431 30.712414 192.168.0.10  194.2.0.36   TCP      1181 > ftp-data [ACK]
...

Les données commencent à venir, il y en a pour un moment. Nous nous retrouvons à la fin du fichier :

614 33.613493 192.168.0.10  194.2.0.36   TCP      1181 > ftp-data [FIN, ACK]
615 33.636771 194.2.0.36    192.168.0.10 TCP      ftp-data > 1181 [ACK]

Voilà, c'est fini. nous arrêtons la transaction avec le serveur FTP :

616 36.666211 192.168.0.10  194.2.0.36   TCP      1175 > ftp [FIN, ACK]
617 36.686973 194.2.0.36    192.168.0.10 TCP      ftp > 1175 [ACK]
618 36.689259 194.2.0.36    192.168.0.10 TCP      ftp > 1175 [FIN, ACK]
619 36.689275 192.168.0.10  194.2.0.36   TCP      1175 > ftp [ACK]
620 38.511841 192.168.0.10  194.2.0.36   TCP      1180 > ftp [FIN, ACK]
621 38.530529 194.2.0.36    192.168.0.10 TCP      ftp > 1180 [ACK]
622 38.533514 194.2.0.36    192.168.0.10 TCP      ftp > 1180 [FIN, ACK]
623 38.533552 192.168.0.10  194.2.0.36   TCP      1180 > ftp [ACK]

Toutes les connexions TCP encore ouvertes sont fermées, y compris le canal de commande initialement ouvert (port 1175).

Déjà beaucoup de choses :

• nous avons mis en évidence la présence du canal de commande et du canal de données, placés sur des connexions TCP différentes,
  
• nous avons, dans ce cas de FTP en mode actif, observé que, pour la création du canal de données, le client FTP :
  • indique au serveur un numéro de port ;
  • se met à l'écoute sur ce port (fonction « serveur TCP ») ;
  • le serveur FTP va quant à lui, utiliser le port 20 pour ce canal de données et agir en client TCP.Ce détail est extrêmement important. Il explique la raison pour laquelle le FTP actif ne fonctionne pas correctement sur des filtres de paquets qui interdisent tout paquet SYN depuis le Net vers la zone protégée. Nous avons vu en effet qu'ici, le serveur FTP initie une nouvelle connexion TCP sur le client FTP (ne nous mélangez pas les pédales entre FTP et TCP…).
    De plus, si le routeur fait du NAT, comme c'est souvent le cas, ça ne va pas être simple de savoir à qui s'adresse cette nouvelle connexion. N'oublions pas que nous regardons ici ce qu'il se passe derrière le NAT. Le serveur FTP, qui est sur le Net, n'a aucune connaissance de l'IP réelle de son client. Pour lui, son interlocuteur, c'est le routeur NAT lui-même, vu du côté Internet, ceci est le travail de Netfilter et des modules du kernel spécialisés dans le traitement de FTP, associés à une règle qui laisse entrer les nouvelles connexion identifiées comme RELATED ;
• nous avons vu également quelques commandes FTP ainsi que quelques codes de réponses ;
  
• enfin, nous avons vu un type de transfert, le type A, qui correspond à de l'ASCII. Mais tout fichier n'est pas forcément de l'ASCII. que va-t-il se passer si le fichier à transporter est, par exemple, une image jpg ?

Bien qu'à ce niveau, si vous êtes toujours là, vous pouvez commencer à lire ces fameuses rfc 765 avec quelques chances d'y comprendre quelque chose, vous sentez bien, n'est-ce pas, qu'il y aurait encore quelques manipulations intéressantes à faire…