Réseau - Web - GNU/Linux

2018 19 octobre

Les différents types de FTP

Rédigé par Marc GUILLAUME | Aucun commentaire

FTP, FTPS et SFTP

Les protocoles les plus couramment utilisés dans le transfert de fichiers aujourd'hui sont peut-être FTP, FTPS et SFTP. Bien que les acronymes de ces protocoles soient similaires, il existe des différences importantes entre eux, en particulier la manière dont les données sont échangées, le niveau de sécurité fourni et les configurations de pare-feu qu'ils supportent. Connaître ces différences clef peut vous aider à choisir un protocole de transfert de fichiers ou à résoudre des problèmes de connexion courants.

FTP

Le protocole FTP (File Transfer Protocol) existe pratiquement depuis les débuts des réseaux TCP/IP et d'Internet. Il a été proposé pour la première fois dans la RFC 114 il y a plus de 40 ans et a finalement évolué vers la RFC 959 qui est la norme que les clients et serveurs FTP suivent de nos jours.

Il a été créé dans des cercles universitaire et était destiné au partage entre gens de bonne compagnie. En pratique toutes les machines disposaient d'IP routables et étaient à la fois clientes et serveur. Les protocoles n'étaient pas chiffrés et l'accès aux serveurs ftp se faisait majoritairement en mode anonyme, où il suffisait, par courtoisie, de fournir son adresse mail en guise de mot de passe.

Ce temps est largement révolu, la plupart des utilisateurs n'ont pas d'IP routables et se trouvent derrière des passerelles NAT utilisant des classes d'IP privées non routables. Si il reste, bien entendu, des gens de bonne compagnie, c'est très loin d'être le cas général. Cela a profondément modifié l'usage de FTP et singulièrement compliqué sa mise en place.

L'échange de données

Le protocole FTP échange des données à l'aide de deux canaux distincts, le canal de commande et le canal de données.

Le canal de commande fonctionne généralement sur le port 21 du serveur et est responsable de l'acceptation des connexions client et de l'échange des commandes simples entre un client FTP et le serveur. Les commandes USER et PASS utilisées pour authentifier un utilisateur FTP sont des exemples de commandes qui sont échangées sur le canal de commande. Le canal de commande reste ouvert jusqu'à ce que le client envoie la commande QUIT pour se déconnecter, ou jusqu'à ce que le serveur déconnecte de force le client, par exemple pour cause d'inactivité.

Le canal de données, qui fonctionne à l'aide de ports temporaires à la demande, écoute sur le serveur (mode passif) ou sur le client (mode actif) et est responsable de l'échange de données sous la forme de listes de répertoires et de transferts de fichiers. Les commandes LIST, STOR et RETR utilisées pour obtenir la liste d'un répertoire du serveur, envoyer un fichier sur le serveur et récupérer un fichier depuis le serveur sont des exemples de commandes (envoyées via le canal de commande) qui ouvrent un canal de données.

Contrairement au canal de commande qui reste ouvert pendant toute la session FTP, le canal de données est fermé une fois le transfert des données terminé. Afin de permettre plusieurs transferts de fichier ou de liste de fichiers simultanés, il faut définir une plage de ports qui doivent être disponibles pour être utilisés en tant que canaux de données.

La sécurité

Dans le protocole FTP, les canaux de commande et de données transmettent les informations en clair. Toutes les données envoyées sur ces canaux peuvent être interceptées et lues.

On peut facilement montrer, avec un analyseur de réseau graphique comme wireshark qu'en effet votre mot de passe est transmis en clair. Nous allons faire une petite expérience avec la configuration suivante.

  • Votre ordinateur de travail (idéalement sous Linux, c'est plus simple) ;
  • un vieux PC récupéré pour le transformer en serveur FTP pour votre réseau ;
  • un hub, ou un switch ou votre box en guise de switch pour que ces deux machines puissent communiquer par le réseau.

Passons sur les confiurations (vous pourrez voir un article pour configurer un serveur avec vsftpd sous Linux). Nous avons donc dans notre réseau :

  • Un serveur ftp qui reçoit de votre box l'IP 192.168.1.69 ;
  • votre propre poste qui lui a l'IP 192.168.1.13 sur lequel vous avez installé wireshark et le client de mail filezilla ;
  • aucune configuration firewall particulière sur les deux postes.

Notre serveur FTP, qui se situe dans votre propre réseau (chez vous derrière votre box), n'utilise aucun chiffrement. Les utilisateurs ont un espace où ils peuvent envoyer et récupérer leurs fichiers en se connectant avec un nom d'utilisateur et un mot de passe.

Postulons que vous avez créé un accès pour l'utilisateur toto avec un joli mot de passe +jGV8Vm>yk&"v>wP.=E>AFgn

Nous allons voir qu'en observant la connexion au serveur ftp depuis filezilla votre mot de passe va apparaître dans wireshark qui ne fait qu'observer les paquets réseau entrant et sortant de votre machine.

Nous allons utiliser wireshark de la façon la plus simple, en lui demandant juste d'écouter les connexions avec notre serveur ftp (IP 192.168.1.69). Pour cela nous utilisons le filtre host 192.168.1.69 :

Puis nous cliquons sur l'icône en haut à gauche ou en utilisant le menu Capture >Démarrer pour commencer à capturer les paquets. Il ne reste plus qu'à lancer la connexion avec FileZilla (ici en utilisant la connexion rapide) :

Et nous voyons dans wireshark que notre beau mot de passe compliqué apparaît en clair :

Un exploit commun, qui tire profit de ce fonctionnement, qui devient de ce fait une vulnérabilité, est l'attaque dite de l'homme du milieu en utilisant l'empoisonnement ARP et un renifleur de paquets qui pourra vous permettre de voir également les mots de passe des autres utilisateurs se connectant à votre ftp.

Et là c'est plus gênant, surtout si il ne s'agit plus de votre propre FTP, mais d'un serveur sur Internet. En fait, sans chiffrement, tous les équipements réseau (routeurs) que traverse votre connexion au FTP distant pourront ou pourraient voir votre mot de passe.

Et avec un pare-feu ?

Les réglages de pare-feu dépendront de votre position, côté serveur ou côté client.

  • Côté serveur : Autoriser les connexions entrantes sur le port 21. Définir la plage de ports passifs (par ex. 2000-2500) pour les transferts de fichiers et les listes de répertoires et autoriser les connexions entrantes sur la plage de ports passifs. Il faudra consulter la documentation de votre logiciel serveur FTP pour savoir comment faire cela (cet article vous donne des explications pour vsftpd).
  • Côté client : Autoriser les connexions sortantes vers le port 21 et la plage de ports passifs définie par le serveur.

La plupart des problèmes de pare-feu rencontrés lors de l'utilisation du FTP sont dus à une mauvaise compréhension des deux modes FTP : le mode actif et le mode passif. Les paramètrages que vous aurez à effectuer sur votre pare-feu côté serveur ou côté client dépendront largement du mode que vous choisissez. Pour éviter ces problèmes, je vous suggère de lire ce billet sur le FTP actif et passif.

FTPS

Lorsque le protocole FTP a été initialement rédigé, la sécurité n'était pas une préoccupation. Depuis lors, beaucoup de choses ont changé et l'envoi de données sur n'importe quel réseau public sans cryptage est considéré comme très risqué et, dans certains cas, interdit. Des réglementations telles que PCI-DSS (sécurisation des payements en ligne) et les diverses réglementations concernant les données de santé ou encore le RGPD (Règlement général sur la protection des données personnelles) édictés par l'UE, par exemple, contiennent des dispositions qui exigent que les transmissions de données soient protégées par chiffrement.

Pour répondre à ces besoins, un ensemble d'extensions de sécurité au protocole FTP original a été proposé dans la RFC 2228 qui protègent les données FTP lorsqu'elles circulent sur le réseau en utilisant le chiffrement TLS (ex SSL).

L'échange de données

Il est le même que pour le FTP simple en clair.

La sécurité

Les variantes sécurisées de FTP comprennent FTPS avec SSL implicite et FTPS avec SSL explicite. Les deux utilisent le chiffrement TLS.

FTPS SSL implicite

En mode SSL implicite, une session TLS est obligatoirement établie entre le client et le serveur avant tout échange de données. Comme son nom l'indique, l'utilisation de SSL/TLS est implicite et toute tentative de connexion faite par un client sans utiliser SSL/TLS est refusée par le serveur. Les services FTPS SSL implicite fonctionnent généralement sur les ports 990 et 989. Bien qu'encore utilisé aujourd'hui, FTPS SSL implicite est considéré par beaucoup comme obsolète en faveur de FTPS SSL explicite qui est parfois désigné dans les clients FTP sous l'appelation FTPES ou EFTS pour le différencier de l'autre. Nous verrons que la grande différence est la manière d'utiliser ces protocoles suivant les configurations de pare-feu en place.

FTPS SSL explicite

En mode SSL explicite, le client et le serveur négocient le niveau de protection utilisé. Ceci est très utile dans la mesure où le serveur peut prendre en charge les sessions FTP non chiffrées et les sessions FTPS chiffrées sur un seul port.

Dans une session SSL explicite, le client établit d'abord une connexion non chiffrée au service FTP. Avant d'envoyer les informations d'identification de l'utilisateur, le client demande au serveur de commuter le canal de commande sur un canal chiffré SSL/TLS en envoyant la commande AUTH TLS ou AUTH SSL. Le client doit donc explicitement demander une connexion chiffrée, d'où le nom du protocole.

Une fois l'installation du canal SSL réussie, le client envoie les informations d'identification de l'utilisateur au serveur FTP. Ces informations d'identification ainsi que toute autre commande envoyée au serveur pendant la session FTP sont automatiquement chiffrées par le canal SSL/TLS. De la même manière que le canal de commande peut être protégé, le niveau de protection utilisé sur le canal de données est négocié entre le client et le serveur en utilisant la commande PROT.

Pare-feu

  • Côté serveur : Autoriser les connexions entrantes sur le port 21 et/ou 990. Définir la plage de ports passifs (par ex. 2000-2500) pour les transferts de fichiers et les listes de répertoires et autoriser les connexions entrantes sur la plage de ports passifs. Consultez la documentation de votre serveur pour savoir comment configurer une plage de ports passifs.
  • Côté client : Autoriser les connexions sortantes vers le port 21 et la plage de ports passifs définie par le serveur.

SFTP

SFTP est souvent confondu avec FTPS et vice-versa, même si ces protocoles n'ont rien en commun, si ce n'est leur capacité à transférer des fichiers en toute sécurité. SFTP est en fait basé sur le protocole SSH (Secure Shell) qui est surtout connu pour son utilisation pour fournir un accès sécurisé aux comptes shell sur les serveurs distants. Pour se connecter en SFTP il n'y a pas besoin d'installer un service FTP sur le serveur, il suffit d'avoir un serveur SSH paramétré pour pouvoir se connecter en SFTP. Ce type de connexion est plus proche de ce que font des outils comme rsync ou scp.

L'échange de données

À la différence de FTP/S, SFTP n'utilise pas deux canaux différents pour les commandes et les données. Les données et les commandes sont transférées dans des paquets spécialement formatés via une seule connexion.

La sécurité

Toutes les données envoyées entre le client et le serveur sont chiffrées à l'aide d'un protocole convenu. Les sessions SFTP peuvent également être protégées par l'utilisation de clés publiques et privées, qui offrent une autre forme d'identification appelée authentification par clé publique. Ceci peut être utilisé comme alternative ou en conjonction avec la forme traditionnelle d'authentification des noms d'utilisateur et des mots de passe.

Contrainte

Les utilisateurs doivent avoir un compte sur le serveur, les utilisateurs anonymes ou n'ayant pas de compte sur le serveur ne peuvent utiliser sftp.

Pare-feu

  • Côté serveur : autoriser les connexions entrantes sur le port 22 (port par défaut de SSH, qui peut-être modifié).
  • Côté client : autoriser les connexions sortantes vers le port 22.

Écrire un commentaire

Quelle est la dernière lettre du mot qgzb ?

Fil RSS des commentaires de cet article

À propos

Yakati.com - Réseau - Web - GNU/Linux © 2017

Généré par PluXml en 0.025s  - Administration

Mes coordonnées

Marc Guillaume
contact[at]yakati.com
79150 ÉTUSSON

Crédits

Pour la gestion du contenu

Généré par PluXml, le Blog ou Cms sans base de données

Pour le contenu

Licence Creative Commons
Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Pour le thème

Thème SOLID de blacktie.co adapté pour PluXml