Alternatives aux ports SFTP

SFTP, qui est souvent confondu avec l'abréviation de « Secure File Transfer Protocol », représente véritablement le protocole de transfert de fichiers SSH. SFTP a été développé au tout début d'Internet et est détaillé dans ce Spécification RFC SFTP. Le protocole SFTP était connu à l’origine sous le nom de simple FTP (File Transfer Protocol). Le protocole FTP prend en charge le transfert de fichiers via le port TCP 21, le port TCP 22 étant utilisé pour SFTP et le port 990 utilisé pour le cryptage implicite TLS/SSL. SFTP est un protocole de transfert de fichiers de base et bien qu'il puisse être assez rapide en raison de sa simplicité, des fonctionnalités supplémentaires telles que le partage de fichiers, la collaboration, l'authentification et l'authentification unique ne sont pas définies pour le protocole.

Au fil du temps, le protocole FTP a été mis à jour pour ajouter le cryptage (SFTP), prendre en charge le cryptage TLS/SSL et améliorer les problèmes de pare-feu/sécurité - par exemple RFC 1579 (février 1994) active le FTP Firewall-Friendly (mode passif), RFC 2228 (juin 1997) propose des extensions de sécurité, RFC 2428 (septembre 1998) ajoute le support pour IPv6 et définit un nouveau type de mode passif.^[8].

Problèmes de traversée du NAT SFTP et du pare-feu

En règle générale, les fournisseurs de services Internet bloquent les ports SFTP pour éviter les problèmes de sécurité et les logiciels malveillants en empêchant l'accès aux fichiers via les ports SFTP. SFTP Nécessite que les ports 22 ou 990 soient ouverts, ce qui est sujet aux logiciels malveillants, notamment aux délinquants notoires comme Wannacry, Sasser, Nimda, Petya/NotPetya, et plus encore. Si les ports STFP sont ouverts, un ordinateur infecté recherchera sur son réseau Windows les partages de serveur acceptant le trafic sur les ports TCP 22 ou 990, indiquant que le système est configuré pour exécuter SFTP. Alors que les pare-feu d'applications Web (WAFS) modernes peuvent être configurés pour surveiller le trafic HTTP, le trafic SFTP n'est pas aussi facilement surveillé.

SFTP transfère les données en répondant du serveur au client après l'envoi d'une commande PORT. C'est un problème pour les pare-feu qui n'autorisent pas les connexions entrantes d'Internet vers les hôtes internes. Il s'agit d'un problème particulier avec Microsoft IIS qui répond avec un port aléatoire.

Les deux approches pour résoudre ce problème consistent soit à configurer le serveur SFTP pour qu'il utilise la commande PASV, soit à utiliser une passerelle au niveau de l'application pour alterner les valeurs de port.

Accès à distance au port SFTP

Pour faciliter l'accès à distance aux fichiers, les entreprises accordent souvent l'accès aux utilisateurs via des serveurs SFTP. Cela fournit un certain niveau d'accès à distance, mais les coûts de support liés à la formation des utilisateurs et au déploiement du logiciel client SFTP sont importants. De plus, SFTP ne s'intègre pas facilement aux serveurs de fichiers existants et à Active Directory pour présenter une expérience de partage de fichiers unifiée. Lorsqu'il accède à des fichiers à distance, l'utilisateur s'attend à accéder facilement à ses lecteurs personnels et partages de service existants sur un lecteur mappé standard prenant entièrement en charge le verrouillage de fichiers, Office et d'autres applications. STFP n'a jamais été conçu pour le partage de fichiers ou la collaboration.

Port SFTP vs HTTP/s

HTTP Le port 443 est un protocole mis à jour qui corrige essentiellement les bogues de SFTP qui le rendaient peu pratique à utiliser pour de nombreux petits transferts.

SFTP utilise une connexion de contrôle avec état qui maintient un répertoire de travail actuel et chaque transfert nécessite une connexion secondaire via laquelle les données réelles sont transférées. En mode "passif", cette connexion supplémentaire est de client à serveur, alors qu'en mode "actif" par défaut, cette connexion est de serveur à client. Ce port SFTP change lorsqu'il est en mode actif, et les numéros de port aléatoires pour tous les transferts, c'est pourquoi les pare-feu et les passerelles NAT ont tant de mal avec SFTP.

La configuration d'une connexion de contrôle SFTP peut être assez lente par rapport à HTTP en raison des retards aller-retour de l'envoi de toutes les commandes requises en attendant une réponse. -établi à chaque fois.

HTTP en comparaison est apatride et multiplexe le contrôle et les données sur une seule connexion du client au serveur sur des numéros de port bien connus, qui passent facilement par les passerelles NAT et sont simples à gérer pour les pare-feu et à rechercher les vulnérabilités de sécurité.

Pourquoi SFTP pourrait-il ne pas être une solution complète de transfert de fichiers alors que les volumes de transfert de fichiers augmentent ?

À mesure que le volume de transferts de fichiers augmente, les limites de SFTP en tant que solution complète de transfert de fichiers deviennent évidentes. Les demandes croissantes d’intégration de davantage de partenaires, de mise à l’échelle de l’infrastructure et de résolution de problèmes techniques peuvent pousser les capacités de SFTP à leurs limites, voire submerger les équipes informatiques. De plus, le besoin de mesures de sécurité renforcées, d’un contrôle strict sur les transactions de fichiers et d’une visibilité robuste pour se conformer aux normes de sécurité et de gouvernance peut dépasser ce que SFTP seul peut offrir.

Pour relever efficacement ces défis, les organisations peuvent découvrir que les solutions de transfert de fichiers gérés (MFT) offrent une approche plus complète. L'utilisation d'un service basé sur le cloud comme Thru, qui exploite divers protocoles tels que SFTP, entre autres, peut fournir des mesures de sécurité améliorées de bout en bout, des mécanismes de suivi précis, des journaux détaillés et des paramètres de rétention à long terme. De plus, les solutions MFT comme Thru peuvent offrir une disponibilité accrue pour garantir que les opérations de transfert de fichiers restent transparentes même si les volumes continuent d'augmenter.

Comment un serveur SFTP s'authentifie-t-il auprès d'un client ?

Pour s'authentifier auprès d'un client, un serveur SFTP initie une négociation TCP à trois voies pour établir une connexion. Ce processus garantit que le serveur et le client ont tous deux accès au bon port (généralement 22) dans la couche de transport. Suite à cette vérification, le serveur utilise l'authentification par paire de clés SSH pour valider l'identité du client. La paire de clés SSH se compose d'une clé publique (partagée entre les deux parties) et d'une clé privée (connue uniquement du client autorisé). Une fois l'authentification SSH terminée avec succès, le transfert de fichiers s'effectue via un canal crypté, avec des données regroupées dans des paquets individuels. Ces paquets sont transmis et réassemblés à la réception pour reconstruire le fichier original en toute sécurité.

Alternative au port SFTP

Le protocole SFTP existe depuis 1980 en tant que mécanisme de transfert de fichiers. Les entreprises resteront légitimement prudentes lorsqu'elles autoriseront ou envisageront les coûts de support de l'accès direct au port SFTP à toute ressource interne à partir de réseaux externes via le protocole FTP/SFTP.

En attendant, MyWorkDrive convertit déjà les partages de fichiers Windows en fichiers sécurisés partages de fichiers accessible en toute sécurité n'importe où à l'aide du port TCP https/SSL 443 sur des protocoles hautement cryptés conformes aux normes RSA 4096 et TLS 1.2 FIPS sans les problèmes de sécurité ou de formation de SFTP.

L'alternative au port MyWorkDrive SFTP prend en charge les travailleurs distants avec notre accès sécurisé basé sur un navigateur Web, Windows Mapped Drive et nos clients mobiles.

Besoin d'aide pour planifier votre alternative SFTP ? Réservez un appel et nous serons heureux de vous aider à planifier votre déploiement.