D'après la sécurité qu'ils fournissent en théorie, FTPS et SFTP sont similaires.En pratique, vous avez les avantages et les inconvénients suivants:

• Avec les applications client FTPS, les applications clientes ne parviennent souvent pas à valider correctement les certificats, ce qui signifie que l'homme au milieu est possible. Avec SFTP à la place, les utilisateurs ignorent simplement les informations sur la clé d'hôte et acceptent n'importe quoi, le résultat est donc le même.
• Mais les utilisateurs et les administrateurs ayant plus de connaissances pourraient utiliser correctement les clés SSH et les utiliser également pour l'authentification. rend alors SFTP beaucoup plus facile à utiliser que l'utilisation de mots de passe. Et si les mots de passe sont interdits du tout, cela est également plus sécurisé car les attaques par mot de passe par force brute ne sont plus possibles.
• FTP utilise des ports dynamiques pour les connexions de données et les informations sur ces ports sont transférées dans la bande. Cela fait déjà du simple FTP (sans TLS) un cauchemar lorsque des pare-feu, NAT ou similaires sont impliqués. Avec FTPS (FTP + TLS), cela devient encore pire car, en raison du cryptage des applications d'assistance de connexion de contrôle sur le pare-feu, ne peuvent plus savoir quels ports doivent être ouverts. Cela signifie que pour réussir FTPS, vous devez ouvrir une large gamme de ports, ce qui est mauvais pour la sécurité (*). SFTP est bien meilleur car il n'utilise qu'une seule connexion pour le contrôle et les données.
• Les serveurs FTP (S) fournissent souvent un accès anonyme et les serveurs SFTP ne le font généralement pas. Plusieurs serveurs FTP (S) proposent également des pseudo utilisateurs, c'est-à-dire des utilisateurs issus de la même base de données ou similaire qui ne sont pas de vrais utilisateurs sur le système. Si vous avez des utilisateurs appropriés de toute façon, cela n'a pas d'importance.
• SFTP utilise le protocole SSH et vous devez configurer correctement le système pour n'autoriser que l'accès SFTP et pas également l'accès SSH (terminal) ou même le transfert SSH. Avec FTP, c'est plus facile car FTP ne peut faire que le transfert de fichiers de toute façon.

(*) Plusieurs commentaires ne croient pas vraiment qu'avoir une large gamme de ports ouverts soit mauvais pour la sécurité. Alors laissez-moi vous expliquer cela plus en détail:

• FTP utilise des connexions TCP distinctes pour le transfert de données. Les ports utilisés pour ces connexions sont dynamiques et les informations à leur sujet sont échangées dans la connexion de contrôle. Un pare-feu qui ne sait pas quels ports sont actuellement utilisés ne peut autoriser qu'une large plage de ports qui sera peut-être utilisée parfois FTP.
• Ces ports doivent permettre l'accès de l'extérieur vers l'intérieur car en mode passif FTP, le le client se connecte à un port dynamique sur le serveur (c'est-à-dire pertinent pour le pare-feu côté serveur) et pour le mode actif FTP, le serveur se connecte à un port dynamique sur le client (pertinent pour le pare-feu côté client).
• Avoir un large la plage de ports ouverts pour un accès illimité de l'extérieur vers l'intérieur n'est pas ce que quelqu'un considère généralement comme un pare-feu restrictif qui protège l'intérieur. Cela ressemble plus à un grand trou dans la porte où un cambrioleur pourrait entrer dans la maison.
• Pour contourner ce problème, la plupart des pare-feu emploient des "helpers" pour FTP qui examinent la connexion de contrôle FTP pour déterminer quels ports doivent être ouverts pour la prochaine connexion de données. Un exemple est ip_conntrack_ftp pour iptables. Malheureusement avec FTPS, la connexion de contrôle est (généralement) cryptée, donc ces assistants sont aveugles et ne peuvent pas ouvrir dynamiquement les ports requis. Cela signifie soit que FTP ne fonctionne pas, soit qu'un large éventail de ports doit être ouvert en permanence.

L'administrateur système soulève un point valable. (mais ses compétences interpersonnelles peuvent nécessiter du travail)

SSH est un protocole complexe, et openssh implémente beaucoup de fonctionnalités. offre des vecteurs d'attaque, et il est très difficile d'être sûr qu'aucun de ces vecteurs ne soit exploitable.

Même si openssh est sans bogues (ce qui n'est pas le cas), connaître toutes les bonnes possibilités pour fermer les fonctionnalités indésirables et comprendre comment ces options peuvent interagir demande un effort considérable en soi. Et ces interactions peuvent changer d'une version à l'autre.

À titre d'exemple, considérons l'extrait de code sshd_config suivant, qui a l'intention de limiter certains utilisateurs uniquement à SFTP (nous avons même pensé à les verrouiller dans leurs répertoires personnels):

  Match Group sftponly ChrootDirectory% h ForceCommand internal-sftp  

Et bien sûr:

 % ssh somehostCe service n'autorise que les connexions sftp.Connexion à somehost clo sed.  

Mais attendez ...

  ssh -N -L 9000: localhost: 80 somehost  

Oups, j'ai maintenant transféré le port 80 sur somehost au port 9000 sur mon hôte, ce qui signifie que nous pouvons nous connecter au port 80 sur somehost comme si nous venions de localhost. ce n'est pas un gros problème pour le port 80, mais qu'en est-il des services qui uniquement écoutent sur l'hôte local, tels que les services administratifs ou les bases de données?

Et ce n'est que du transfert TCP. À tout le moins, SSH permet également le transfert X11 et le transfert d'agent SSH, et je ne connais même pas les implications de ces deux.

Nous utilisons beaucoup ssh / sftp, car pour notre situation, les avantages l'emportent sur ces risques. Mais c'est une préoccupation valable qui ne doit pas être prise à la légère. ForceCommand internal-sftp

Nous espérons que cela est suffisant pour garantir seulement l'accès sftp, mais nous ne pouvons pas en être complètement sûrs. (suggestions bienvenues;)

Les deux protocoles ont des avantages et des inconvénients, comme expliqué très bien dans cet article de comparaison.

Ceci dit, étant donné que la question concerne spécifiquement la sécurité, il y a quelques considérations qui doit être pris en compte lors du choix du meilleur protocole dans certaines conditions spécifiques.

FTPS et FTPES utilisent SSL ou TLS pour crypter le contrôle / les données Connexions. Le principal avantage de ces canaux sécurisés est qu'ils utilisent des certificats X.509, qui contiennent beaucoup plus d'informations qu'une simple paire de clés (nom d'hôte, adresse email, nom de l'organisation, l'ISSUER (CA), ...) et sont donc un beaucoup plus facile à valider. Mais:

• SSL 1.0 , SSL 2.0 : obsolète depuis longtemps (non sécurisé)
• SSL 3.0 : récemment obsolète en raison de POODLE
• TLS 1.0 : n'est plus acceptable pour la conformité PCI
• TLS 1.1 : manque certaines des extensions de TLS 1.2, et a un support client limité, aucune raison de l'utiliser
• TLS 1.2 : norme actuelle, jusqu'à présent considérée comme sécurisée / sûre

Et ce qui précède ne couvre que le protocole de cryptage des canaux, alors il y a des considérations de sécurité concernant le protocole FTP lui-même. La commande SITE , par exemple, a été utilisée à maintes reprises pour perpétrer des attaques, et la conception inhérente du protocole lui-même nécessite d'ouvrir et de NAT plusieurs ports sur votre pare-feu (ce qui peut devenir un cauchemar à gérer. ). En outre, la plupart des pare-feu ne sont pas en mesure de NAT correctement les connexions de données FTP à moins que le client ne le demande et que le serveur autorise CCC (Clear Control Channel) qui met en échec une partie de la sécurité en exécutant la connexion de contrôle non chiffrée.

D'autre part, nous avons SFTP , qui est un sous-système de SSH . Le principal défi ici est que les clés SSH ne sont "que des clés", elles ne sont pas émises par une autorité de certification et aucune déclaration de l'émetteur ni aucun porte-clés n'est inclus, par conséquent, les clés de serveur SSH doivent être expressément approuvées par le client

Quelques avantages secondaires remarquables de SFTP, cependant, incluent:

De nombreuses personnes évoquent des points valables sur les différences entre les deux protocoles. Mais je pense que pour vos besoins, la question est vraiment "SFTP est-il suffisamment sécurisé?" plutôt que "lequel est le plus sûr" ?. Comme vous l'avez dit, vous avez d'autres préoccupations que la simple sécurité.

Cela s'avère être un problème difficile à résoudre. SSH a été largement utilisé et étudié de manière approfondie. Il n'y a pas de défauts de conception de protocole connus. Cependant, les vulnérabilités de sécurité n'ont souvent rien à voir avec le protocole, et tout à voir avec l'implémentation. Après tout, SMTP lui-même n'est pas "non sécurisé", et sa conception est relativement simple, mais il y a 16 ans, l'application Commmon SendMail était l'un des enfants de l'affiche de la sécurité logicielle mal implémentée, et avait trou après trou.

Le fait est que, même si le protocole est bien conçu et simple, la mise en œuvre peut être un nid de rats de complexité, d'ajouter des fonctionnalités et des cauchemars de sécurité.

Donc, je pense que ceci Il s'agit plus de choisir une bonne MISE EN ŒUVRE plutôt qu'un bon protocole. Les deux protocoles sont bons, et les deux implémentations peuvent être mal implémentées.

Je ne suis pas tout à fait familier avec FTPS, donc je ne sais pas s'il existe des implémentations bien respectées de celui-ci. Pour SSH cependant, OpenSSH est généralement considéré comme de haute qualité et a été conçu avec la sécurité à l'esprit dès le départ (séparation des privilèges, etc.).

Comme vous, je pensais que les deux étaient presque les mêmes lorsque j'ai parcouru le Web à la recherche de leurs différences.

Cependant, dans la vraie vie, c'est une autre histoire. Voici mon expérience:

1. Pour mon NAS, j'ai activé la fonctionnalité FTPS pendant 3 mois. La configuration du pare-feu était correcte. Je devais juste ouvrir le port FTP et quelques ports supplémentaires utilisés par le transfert FTPS. Jusqu'ici tout va bien, pas grand-chose.

2. Après 3 mois, je pense, meh, peut-être que j'active le protocole SFTP aussi car il est plus courant et probablement plus facile à gérer. Puis quelque chose d'intéressant s'est produit. 10 MINUTES après avoir ouvert le port SFTP, mon NAS était soumis à des attaques de force de contusion. Le NAS a automatiquement bloqué l'adresse IP attaquante après 10 tentatives infructueuses de mot de passe et m'avertit par e-mail. Imaginez que si l'attaquant contrôlait des milliers d'ordinateurs ayant tous des adresses IP différentes, mon NAS ne serait pas en mesure de les arrêter tous. De plus, si le personnel de notre entreprise décide de configurer un mot de passe très simple, la personne qui utilise l'attaque par force de contusion peut éventuellement entrer dans notre système.

Maintenant que je désactivé le SFTP, l'attaque a cessé et je suis heureux que personne n'essaie plus d'entrer dans notre serveur de fichiers.

Non, SSH et SSL utilisent généralement le même niveau de chiffrement. Par exemple: RSA et AES, mais SSH peut utiliser DSA. Mais ssh utilise le port 22. mais les FTP utilisent les ports 21 et 22 pour les données FTP et FTP. bien qu'il soit à mon avis mieux configurable, vous devez ouvrir 2 ports, ce qui n'est pas seulement peu pratique compte tenu des pare-feu, mais aussi un risque de sécurité potentiel, car vous devez ouvrir 2 ports.

La réponse est un peu brutale de la façon dont vous allez dans votre rhétorique. Les moyens côté serveur sont contrôlés par la personne qui donne le fichier et théoriquement plus sûrs si l'on connaît toutes les fonctionnalités de sécurité.

Une méthode côté utilisateur serait la même mais pour l'utilisateur. De nos jours, nous ne remettons pas en question la relation entre les deux. Chacun doit s'assurer de sa capacité à se protéger suffisamment. Les utilisateurs se tournent donc vers une option de pare-feu.

Toute option que vous choisissez pour l'utilisateur peut facilement être annulée par de tels moyens. Par conséquent, nous ne nous soucions pas de l'utilisateur (destinataire). Cette rhétorique est désormais obsolète sur cette question.

Votre préoccupation devrait porter sur vos propres valeurs. Cela signifierait côté serveur. Vous voulez contrôler les informations que vous publiez. Le degré d'inquiétude après sa publication n'est plus prudent. Ce n'est tout simplement pas votre responsabilité au-delà de ce point. Seulement ce qui vous affecte en conséquence. Si vous n'avez pas encore de données à ce sujet, vous n'avez aucune conséquence.

Une solution vraiment contrôlable serait d'utiliser une source FTP avec un cryptage de votre propre conception. Ne vous fiez à aucun tiers. Mais cela aussi est obsolète car il est difficile de construire vos propres bibliothèques du début à la fin.

Sur la base des terminologies que vous avez mal fournies, vous voulez un simple ftp ssh. Pour cela, tout ce que vous pouvez faire est de proposer des règles de pare-feu et des configurations iptables (si sous Linux). Vous semblez être coincé avec WYSIWYG dans tous les cas.