Présentation
L'une des questions les plus fréquemment posées lorsqu'il s'agit de pare-feu et d'autres problèmes de connectivité Internet est la différence entre le FTP (File Transfer Protocol) actif et passif et la meilleure façon de prendre en charge l'un ou l'autre ou les deux. Espérons que le texte suivant aidera à dissiper une partie de la confusion sur la prise en charge du FTP dans un environnement pare-feu.
Cet article comprend des exemples de sessions FTP en ligne de commande actives et passives. Ces exemples de session devraient aider à clarifier un peu les choses. Ils fournissent également une belle image de ce qui se passe dans les coulisses lors d'une session FTP. Passons maintenant aux informations…
Les bases
FTP est un service basé exclusivement sur TCP. Il n'y a pas de composant UDP pour FTP. FTP est un service inhabituel en ce sens qu'il utilise deux ports, un port "données" et un port "commande" (également appelé port de contrôle). Traditionnellement, il s'agit du port 21 pour le port de commande et du port 20 pour le port de données. La confusion commence cependant lorsque l'on constate que selon le mode, le port de données n'est pas toujours sur le port 20.
FTP actif
En mode FTP actif, le client se connecte à partir d'un port aléatoire non privilégié (N> 1024) au port de commande du serveur FTP, le port 21. Ensuite, le client commence à écouter le port N+1 et envoie la commande FTP PORT N+1 au FTP serveur. Le serveur se reconnectera ensuite au port de données spécifié du client à partir de son port de données local, qui est le port 20.
Du point de vue du pare-feu côté serveur, pour prendre en charge le FTP en mode actif, les canaux de communication suivants doivent être ouverts :
- Port 21 du serveur FTP depuis n'importe où (le client initie la connexion)
- Port 21 du serveur FTP vers ports> 1024 (le serveur répond au port de contrôle du client)
- Port 20 du serveur FTP vers les ports > 1024 (le serveur initie une connexion de données vers le port de données du client)
- Port 20 du serveur FTP depuis les ports > 1024 (le client envoie des ACK au port de données du serveur)
Lorsqu'elle est tracée, la connexion apparaît comme suit :
- Du port client 1026 (Cmd) au port serveur 21 (Cmd)
- Du port serveur 21 (Cmd) au port client 1026 (Cmd)
- Du port 20 du serveur (données) au port client 1027 (données)
- Du port client 1027 (données) au port serveur 20 (données)
À l'étape 1, le port de commande du client contacte le port de commande du serveur et envoie la commande PORT 1027. Le serveur renvoie ensuite un ACK au port de commande du client à l'étape 2. À l'étape 3, le serveur initie une connexion sur son port de données local pour le port de données que le client a spécifié précédemment. Enfin, le client renvoie un ACK comme indiqué à l'étape 4.
Le principal problème avec le FTP en mode actif se situe en fait du côté client. Le client FTP n'établit pas la connexion réelle au port de données du serveur - il indique simplement au serveur sur quel port il écoute et le serveur se reconnecte au port spécifié sur le client. Du côté du pare-feu du client, cela semble être un système extérieur initiant une connexion à un client interne, ce qui est généralement bloqué.
Exemple de FTP actif
Vous trouverez ci-dessous un exemple réel d'une session FTP active. Les seules choses qui ont été modifiées sont les noms de serveur, les adresses IP et les noms d'utilisateur. Dans cet exemple, une session FTP est initiée depuis user01 (192.0.0.1), une machine Solaris exécutant le client de ligne de commande FTP standard, vers dest_serv (192.0.0.2), une machine Solaris exécutant Solaris[TM] 9 ftpd . L'indicateur de débogage (-d) est utilisé avec le client FTP pour montrer ce qui se passe dans les coulisses. Tout ce qui est en italique est la sortie de débogage qui montre les commandes FTP réelles envoyées au serveur et les réponses générées à partir de ces commandes.
Il y a quelques points intéressants à considérer à propos de cette boîte de dialogue. Notez que lorsque la commande PORT est émise, elle spécifie un port sur le système client (192.0.0.1) plutôt que sur le serveur. Nous verrons le comportement inverse lorsque nous utiliserons le FTP passif. Pendant que nous y sommes, une note rapide sur le format de la commande PORT. Comme vous pouvez le voir dans l'exemple ci-dessous, il est formaté comme une série de six nombres séparés par des virgules. Les quatre premiers octets sont l'adresse IP tandis que les deux seconds octets comprennent le port qui sera utilisé pour la connexion de données. Pour trouver le port réel, multipliez le cinquième octet par 256, puis ajoutez le sixième octet au total. Ainsi, dans l'exemple ci-dessous, le numéro de port est ((256*188) + 231), soit 48359. Une vérification rapide avec netstat devrait confirmer cette information.
$ ftp -d dest_serv Connected to dest_serv. 220 dest_serv FTP server ready. Name (dest_serv:boqueron): root ---> USER root 331 Password required for root. Password: ---> PASS XXXX 230 User root logged in. ---> SYST 215 UNIX Type: L8 Version: SUNOS Remote system type is UNIX. ---> TYPE I 200 Type set to I. Using binary mode to transfer files. ftp> ls ---> PORT 192,0,0,1,188,231 200 PORT command successful. ---> TYPE A 200 Type set to A. ---> NLST 150 Opening ASCII mode data connection for file list. TT_DB bin (...) var vol xfn 226 Transfer complete. 191 bytes received in 0.03 seconds (6.16 Kbytes/s) ---> TYPE I 200 Type set to I. ftp> quit ---> QUIT 221-You have transferred 0 bytes in 0 files. 221-Total traffic for this session was 599 bytes in 1 transfers. 221-Thank you for using the FTP service on dest_serv. 221 Goodbye. # netstat -a | grep 48359 dest_serv.ftp-data user01.48359 33580 0 49640 0 TIME_WAIT
FTP passif
Afin de résoudre le problème du serveur qui initie la connexion au client, une méthode différente pour les connexions FTP a été développée. C'était ce qu'on appelait le mode passif, ou PASV, d'après la commande utilisée par le client pour indiquer au serveur qu'il était en mode passif.
En mode FTP passif, le client initie les deux connexions au serveur, résolvant le problème des pare-feux filtrant la connexion du port de données entrant vers le client depuis le serveur. Lors de l'ouverture d'une connexion FTP, le client ouvre localement deux ports aléatoires non privilégiés (N> 1024 et N+1). Le premier port contacte le serveur sur le port 21, mais au lieu d'émettre ensuite une commande PORT et de permettre au serveur de se reconnecter à son port de données, le client émettra la commande PASV. Le résultat est que le serveur ouvre alors un port aléatoire non privilégié (P> 1024) et renvoie la commande PORT P au client. Le client initie alors la connexion du port N+1 au port P sur le serveur pour transférer les données.
Du point de vue du pare-feu côté serveur, pour prendre en charge le FTP en mode passif, les canaux de communication suivants doivent être ouverts :
- Port 21 du serveur FTP depuis n'importe où (le client initie la connexion)
- Port 21 du serveur FTP vers ports> 1024 (le serveur répond au port de contrôle du client)
- Ports du serveur FTP > 1024 depuis n'importe où (le client initie une connexion de données vers un port aléatoire spécifié par le serveur)
- Ports du serveur FTP> 1024 vers ports distants> 1024 (le serveur envoie des ACK (et des données) au port de données du client)
Lorsqu'elle est dessinée, une connexion FTP en mode passif ressemble à ceci :
- Du port client 1026 (Cmd) au port serveur 21 (Cmd)
- Du port serveur 21 (Cmd) au port client 1026 (Cmd)
- Du port client 1027 (données) au port serveur 2024
- Du port serveur 2024 (Cmd) au port client 1027 (données)
À l'étape 1, le client contacte le serveur sur le port de commande et émet la commande PASV. Le serveur répond ensuite à l'étape 2 avec le PORT 2024, indiquant au client sur quel port il écoute la connexion de données. À l'étape 3, le client initie ensuite la connexion de données de son port de données au port de données spécifié du serveur. Enfin, le serveur renvoie un ACK à l'étape 4 au port de données du client.
Alors que le FTP en mode passif résout de nombreux problèmes côté client, il ouvre toute une gamme de problèmes côté serveur. Le plus gros problème est la nécessité d'autoriser toute connexion à distance à des ports à numéro élevé sur le serveur. Heureusement, de nombreux démons FTP, y compris le démon solaris in.ftpd, permettent à l'administrateur de spécifier une plage de ports que le serveur FTP utilisera. Voir l'annexe 1 pour plus d'informations.
Le deuxième problème concerne la prise en charge et le dépannage des clients qui prennent (ou ne prennent pas en charge) le mode passif. Par exemple, l'utilitaire FTP de ligne de commande fourni avec le démon ftp Solaris prend en charge le mode passif depuis Solaris 9 (à partir de sccs v1.20). Jetez un œil aux pages de manuel (in.ftpd), option -p.
Avec la popularité massive du World Wide Web, de nombreuses personnes préfèrent utiliser leur navigateur Web comme client FTP. La plupart des navigateurs ne prennent en charge que le mode passif lors de l'accès aux URL ftp://. Cela peut être bon ou mauvais selon ce que les serveurs et les pare-feu sont configurés pour prendre en charge.
Exemple de FTP passif
Vous trouverez ci-dessous un exemple concret de session FTP passive. Les seules choses qui ont été modifiées sont les noms de serveur, les adresses IP et les noms d'utilisateur. Dans cet exemple, une session FTP est initiée depuis user01 (192.0.0.1), une machine Solaris exécutant le client de ligne de commande FTP standard, vers dest_serv (192.0.0.2), une machine Solaris exécutant Solaris 9 ftpd. L'indicateur de débogage (-d) est utilisé avec le client FTP pour montrer ce qui se passe dans les coulisses. Tout ce qui est en italique est la sortie de débogage qui montre les commandes FTP réelles envoyées au serveur et les réponses générées à partir de ces commandes. La sortie normale du serveur est affichée en noir et l'entrée de l'utilisateur est en gras .
Notez la différence entre la commande PORT dans cet exemple et l'exemple FTP actif. Ici, nous voyons un port ouvert sur le système serveur (192.0.0.2), plutôt que sur le client. Voir la discussion sur le format de la commande PORT ci-dessus, dans la section Active FTP Example.
$ ftp -d dest_serv Connected to dest_serv. 220 dest_serv FTP server ready. Name (dest_serv:boqueron): root ---> USER root 331 Password required for root. Password: ---> PASS XXXX 230 User root logged in. ---> SYST 215 UNIX Type: L8 Version: SUNOS Remote system type is UNIX. ---> TYPE I 200 Type set to I. Using binary mode to transfer files. ftp> passive Passive mode on. ftp> ls ---> PASV 227 Entering Passive Mode (192,0,0,2,7,176) ---> TYPE A 200 Type set to A. ---> NLST 150 Opening ASCII mode data connection for file list. TT_DB bin cdrom (...) vol xfn 226 Transfer complete. 191 bytes received in 0.027 seconds (7.04 Kbytes/s) ---> TYPE I 200 Type set to I. ftp> quit ---> QUIT 221-You have transferred 0 bytes in 0 files. 221-Total traffic for this session was 599 bytes in 1 transfers. 221-Thank you for using the FTP service on dest_serv. 221 Goodbye.
Résumé
Le tableau suivant devrait aider les administrateurs à se souvenir du fonctionnement de chaque mode FTP :
Active FTP : command : client >1024 -> server 21 data : client >1024 <- server 20 Passive FTP : command : client >1024 -> server 21 data : client >1024 -> server >1024
Un bref résumé des avantages et des inconvénients du FTP actif par rapport au FTP passif s'impose également :
Le FTP actif est bénéfique pour l'administrateur du serveur FTP, mais préjudiciable à l'administrateur côté client. Le serveur FTP tente d'établir des connexions à des ports élevés aléatoires sur le client, qui seraient presque certainement bloqués par un pare-feu côté client. Le FTP passif est bénéfique pour le client, mais préjudiciable à l'administrateur du serveur FTP. Le client établira les deux connexions au serveur, mais l'une d'elles sera à un port haut aléatoire, qui serait presque certainement bloqué par un pare-feu côté serveur.
Heureusement, il y a un peu de compromis. Étant donné que les administrateurs exécutant des serveurs FTP devront rendre leurs serveurs accessibles au plus grand nombre de clients, ils devront presque certainement prendre en charge le FTP passif. L'exposition des ports de haut niveau sur le serveur peut être minimisée en spécifiant une plage de ports limitée à utiliser par le serveur FTP. Ainsi, tout sauf cette plage de ports peut être protégé par un pare-feu côté serveur. Bien que cela n'élimine pas tous les risques pour le serveur, cela les diminue considérablement. Voir l'annexe 1 pour plus d'informations.