FTPS (FTP + S) offre-t-il une meilleure sécurité que SFTP côté serveur?
Hier, j'ai eu un échange avec un administrateur système tiers concernant la configuration d'une interface de transfert de fichiers entre nos serveurs.
J'ai suggéré d'utiliser SFTP parce que notre application le supporte bien. Mon interlocuteur veut absolument FTP + S (FTP + TLS) que nous ne supportons pas actuellement et que nous aurions besoin de développer.
J'ai soutenu que je ne voyais aucun avantage réel dans FTP + S sur SFTP car les deux offrent un cryptage de trafic solide. SFTP est facilement disponible et peut être encore plus sécurisé avec l'authentification par clé publique. Enfin et surtout, son mode de connexion unique le rend beaucoup plus agréable à utiliser derrière les pare-feu d'entreprise.
L'administrateur système m'a presque appelé un idiot, déclarant que SFTP fonctionne au-dessus de SSH qui est un protocole conçu à des fins d'administration, et qu'ouvrir un port SSH pour toute autre utilisation que l'administration est clairement une mauvaise idée car il ouvre un large vecteur d'attaque contre le système hôte.
Je me demande si cet argument est valable. Il semble qu'il existe différentes façons de restreindre une session SSH pour autoriser uniquement le transfert de fichiers SFTP. Il y a le sous-système internal-sftp fourni avec openSSH, où vous pouvez facilement configurer un chroot et désactiver TCP transfert. J'ai même entendu parler de solutions qui permettent vraisemblablement aux utilisateurs de se connecter via SFTP sans avoir besoin d'un entrée dans le fichier passwd ... Je ne vois aucun problème clair avec SFTP que vous n'auriez pas avec FTP + S, mais je pourrais manquer quelque chose?
Donc, malgré les restrictions que vous pouvez appliquer à SSH, FTP + S est-il une meilleure option pour les transferts de fichiers, en termes de sécurité?
De 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, il arrive souvent que les certificats ne soient pas validés correctement, ce qui signifie que l'homme au milieu est possible. Avec SFTP, les utilisateurs ignorent simplement les informations sur la clé hôte et acceptent tout, le résultat est donc le même.
- Mais les utilisateurs et les administrateurs disposant de plus de connaissances pourraient utiliser correctement les clés SSH et les utiliser également pour l'authentification, ce qui rend SFTP beaucoup plus facile à utiliser que l'utilisation de mots de passe. Et si les mots de passe sont interdits, cela est également plus sûr 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 rend déjà FTP simple (sans TLS) un cauchemar lorsque des pare-feu, NAT ou similaire sont impliqués. Avec FTPS (FTP + TLS), cela devient encore pire car en raison du cryptage de l'aide à la connexion de contrôle les applications sur le pare-feu ne peuvent plus savoir quels ports doivent être ouverts. Cela signifie que pour passer FTPS, vous devez ouvrir une large gamme de ports, ce qui est mauvais pour la sécurité (*). SFTP est bien meilleur car il utilise uniquement un connexion unique 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) offrent également des pseudo-utilisateurs, c'est-à-dire des utilisateurs provenant de la même base de données ou similaires qui ne sont pas de vrais utilisateurs sur le système. Si vous n'avez de bons utilisateurs que de toute façon, cela n'a pas d'importance.
- SFTP utilise le protocole SSH et vous devez configurer le système correctement 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 de toute façon que transférer des fichiers.
(*) Plusieurs commentaires ne croient pas vraiment qu'avoir un large éventail de ports ouverts est mauvais pour la sécurité. Permettez-moi donc d'expliquer cela plus en détail:
- FTP utilise des connexions séparées TCP pour le transfert de données. Les ports utilisés pour ces connexions sont dynamiques et les informations à ce 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 parfois utilisée par FTP.
- Ces ports doivent permettre l'accès de l'extérieur vers l'intérieur car en mode passif FTP, le client se connecte à un port dynamique du 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 du client (pertinent pour le pare-feu côté client).
- Avoir un large éventail de ports ouverts pour 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 gros trou dans la porte où un cambrioleur pourrait entrer dans la maison.
- Pour contourner ce problème, la plupart des pare-feu utilisent des "assistants" 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, ces assistants sont donc aveugles et ne peuvent pas ouvrir dynamiquement les ports requis. Cela signifie que FTP ne fonctionne pas ou qu'un large éventail de ports doit être ouvert tout le temps.
L'administrateur système soulève un point valide. (mais ses compétences interpersonnelles pourraient nécessiter du travail)
SSH est un protocole complexe et openssh implémente de nombreuses fonctionnalités. Toutes ces fonctionnalités offrent des vecteurs d'attaque, et il est très difficile de s'assurer qu'aucun de ces vecteurs n'est 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 pourraient interagir nécessite un effort considérable en soi. Et ces interactions peuvent changer d'une version à l'autre.
Par exemple, considérons les éléments suivants sshd_config extrait, qui a l'intention de limiter certains utilisateurs à SFTP uniquement (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 somehost
This service allows sftp connections only.
Connection to somehost closed.
Mais attendez...
ssh -N -L 9000:localhost:80 somehost
Oups, j'ai maintenant transféré le port 80 sur somehost vers le port 9000 sur mon hôte. Cela signifie que nous pouvons nous connecter au port 80 sur somehost comme si nous venions de localhost. Probablement 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 c'est juste TCP transfert. À 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. Nous nous sommes retrouvés avec ceci pour des cas d'utilisation où juste sftp est suffisant:
Match Group sftponly
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
ForceCommand internal-sftp
Nous espérons que cela est suffisant pour garantir juste l'accès sftp, mais nous ne pouvons pas ê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 .
Cela dit, étant donné que la question concerne spécifiquement la sécurité, il y a quelques considérations à prendre en compte lors du choix du protocole qui convient le mieux dans certaines conditions spécifiques.
[~ # ~] ftps [~ # ~] et [~ # ~] ftpes [~ # ~] utilisez SSL ou TLS pour crypter les connexions de contrôle/données. 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 e-mail, nom de l'organisation, l'émetteur (CA), ...) et sont donc un beaucoup plus facile à valider. Mais:
- SSL 1.0 , SSL 2.0 : obsolète il y a longtemps (non sécurisé)
- SSL 3.0 : récemment déconseillé 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'ici considérée comme sécurisée/sûre
Et ce qui précède ne couvre que le protocole de cryptage des canaux, puis 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 à plusieurs reprises pour perpétrer des attaques, et la conception inhérente de le protocole lui-même nécessite d'ouvrir et NAT plusieurs ports sur votre pare-feu (ce qui peut devenir un cauchemar à gérer). De plus, la plupart des pare-feu ne peuvent pas correctement NAT = Connexions de données FTP à moins que le client ne le demande et que le serveur autorise [~ # ~] ccc [~ # ~] (Clear Control Channel), ce qui défait 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", qu'elles ne sont pas émises par une autorité de certification et qu'aucune déclaration d'émetteur ou chaîne de clés n'y est incluse, donc les clés de serveur SSH doivent être expressément approuvé par le client .
Quelqu'un peut soutenir que la configuration d'un serveur SSH pour autoriser uniquement SFTP (pas de shell, pas de commandes, pas de tunnels de transfert, pas de X11) peut être difficile. Cela dépend en fait: si vous utilisez Linux et OpenSSH, cela pourrait être vrai, mais il y a une pléthore de serveurs SSH/SFTP qui font de ce type de configuration un jeu d'enfant, donc je ne répertorierais pas nécessairement cela comme un défaut potentiel, à moins - comme je l'ai dit - que Linux/OpenSSH soient utilisés.
Cependant, quelques avantages secondaires remarquables du SFTP comprennent:
- Échange de clé ECDSA : une clé ECDS (X) de 521 bits équivaut à une clé RSA de 15 360 bits en termes de sécurité, et nécessite 9 fois moins Cycles CPU pour le calcul de la signature
- Inhérent secret de retransmission: le protocole SSH peut renégocier la clé de cryptage de canal réelle en session, et fournit un secret de retransmission inhérent, comme contrairement à tout serveur compatible SSL/TLS qui nécessite un travail de configuration supplémentaire pour y parvenir
Donc, en fin de compte, le choix vous appartient vraiment, mais l'argument que le sysadmin faisait était manifestement invalide, et s'il existe un serveur SFTP existant qui est bien configuré (comme expliqué), il n'y a aucune raison (surtout pas de sécurité - raison connexe) pour passer à FTPS (ou FTPES).
Beaucoup de gens soulèvent 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. Le SSH a été largement utilisé et étudié de manière approfondie. Il n'y a pas de défaut de conception de protocole connu. Cependant, les failles de sécurité n'ont souvent rien à voir avec le protocole et tout à voir avec la mise en œuvre. Après tout, SMTP lui-même n'est pas "non sécurisé" et est relativement simple dans sa conception, mais il y a 16 ans, l'application commune SendMail était l'un des enfants de l'affiche de la sécurité des logiciels 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 complexité pour les rats, des fonctionnalités supplémentaires et des cauchemars de sécurité.
Je pense donc qu'il s'agit davantage de choisir une bonne MISE EN ŒUVRE plutôt qu'un bon protocole. L'un ou l'autre protocole est correct et l'une ou l'autre implémentation peut être mal implémentée.
Je ne connais pas entièrement FTPS, donc je ne sais pas s'il existe des implémentations bien respectées. Cependant, pour SSH, 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 privée, etc.).
Comme vous, je pensais que les deux étaient presque les mêmes lorsque je parcourais le Web à la recherche de leurs différences.
Cependant, dans la vraie vie, c'est une autre histoire. Voici mon expérience:
Pour mon NAS, j'ai activé la fonctionnalité FTPS pendant 3 mois. La configuration du pare-feu était correcte. J'ai juste eu à ouvrir le port FTP et quelques autres ports utilisés par le transfert FTPS. Jusqu'ici tout va bien, ce n'est pas grave.
Après 3 mois, je pense, meh, peut-être que j'active également le protocole SFTP 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 a subi des attaques par contusion. Le NAS a automatiquement bloqué l'adresse IP attaquante après 10 tentatives de mot de passe infructueuses et prévenez-moi par e-mail. Imaginez que l'attaquant ait le contrôle de milliers d'ordinateurs ayant tous des IP différentes, mon NAS ne serait pas en mesure de les arrêter tous. Aussi, si le personnel de notre entreprise décide de mettre en place un mot de passe vraiment simple, alors la personne qui utilise l'attaque par ecchymose peut éventuellement entrer dans notre système.
Maintenant que j'ai désactivé le SFTP, l'attaque a cessé et je suis heureux que personne n'essaye plus d'entrer dans notre serveur de fichiers.