FTP n'est-il pas sûr?
D'accord, nous connaissons l'exercice: n'utilisez pas FTP , utilisez SFTP ou FTPS .
Mais quel est exactement le risque posé? Les fichiers eux-mêmes sont envoyés non cryptés, ce qui peut être correct ou désastreux, selon le contenu du code. Mais, si nous avons affaire à des fichiers HTML statiques (ou similaires), cela est probablement correct?
Qu'en est-il des informations d'identification, du mot de passe, etc. d'un utilisateur? Sont-ils protégés lors de l'utilisation de Vanilla FTP? Et si oui, est-ce "adéquat"?
Je demande très honnêtement comme mesure de la qualité de vie. Mon alternative pour mettre à jour les fichiers de base sur un serveur public serait autrement avec un processus compliqué de clés SSH, etc. en utilisant des systèmes qui, pour la durée de vie, ne peuvent pas se souvenir de mon mot de passe lorsqu'il est envoyé via SFTP.
Accorder le réseau particulier sur lequel on est est également important. Un réseau de bureaux sécurisé est un peu différent d'un salon d'aéroport.
Avec FTP simple, les informations d'identification sont transmises en clair et peuvent donc être facilement détectées. De plus, les fichiers sont non seulement envoyés en clair, mais ils ne sont pas non plus protégés contre les modifications, c'est-à-dire qu'un homme actif au milieu peut modifier les fichiers à la volée. Dans la mesure où les risques sont similaires à ceux du HTTP standard, c'est-à-dire que cela pourrait être bien au sein d'un réseau de confiance, mais c'est une mauvaise idée si vous ne pouvez pas faire entièrement confiance au réseau.
Les informations d'identification sont transférées en texte clair, mais vous le savez depuis les autres messages. Mais est-il facile d'obtenir ces détails?
À titre d'exemple, j'ai exécuté tcpdump et je me suis connecté à un serveur FTP. Jetons un coup d'œil au pcap avec des chaînes:
220 (vsFTPd 3.0.2)
6USER joe
CT'X
331 Please specify the password.
CTXY
PASS superSecretPassword
230 Login successful.
Qu'en est-il du contenu des commandes? Voici la sortie du pcap:
PASV
227 Entering Passive Mode (192,168,1,2,238,178).
LIST
150 Here comes the directory listing.
MNt@
drwxr-xr-x 2 1000 1000 4096 Aug 28 20:27 Desktop
drwxr-xr-x 2 1000 1000 4096 Aug 28 20:27 Documents
drwxr-xr-x 2 1000 1000 4096 Aug 28 20:27 Downloads
drwxr-xr-x 2 1000 1000 4096 Aug 28 20:27 Music
-rw-rw-r-- 1 1000 1000 58677 Jun 12 2010 pic1.jpg
Et si vous vouliez du contenu de fichier, voici un aperçu du jpg.
200 Switching to Binary mode.
PASV
227 Entering Passive Mode (192,168,1,2,64,224).
RETR pic1.jpg
150 Opening BINARY mode data connection for pic1.jpg (58677 bytes).
JFIF
http://ns.Adobe.com/xap/1.0/
<?xpacket begin="
" id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="Adobe:ns:meta/"
x:xmptk="XMP Core 4.1.1"> <rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
Donc, si quelqu'un peut renifler des paquets sur le client, le serveur ou le réseau, vous avez un problème de sécurité. Atténuer le problème en déplaçant le SFTP ou similaire est une idée facile et bonne.
Dans quelle mesure… vraiment… est FTP?
Aussi peu sûr que tout autre protocole de couche application non chiffré, par exemple HTTP.
Mais quel est exactement le risque posé?
Le risque majeur est l'exposition (aux écoutes du réseau) de toutes les données envoyées via FTP.
Qu'en est-il des informations d'identification, du mot de passe, etc. d'un utilisateur?
Oui, ceux-ci sont également exposés. Ils sont envoyés à l'aide des commandes de couche application USER et PASS.
Comment l'insécurité… vraiment… est FTP
C'est aussi peu sûr que votre réseau. Si le réseau peut être reniflé (WiFi, FAI escroc, etc.), trouver le mot de passe et les données est aussi trivial que d'exécuter Wirehark. Étant donné un point à écouter, vous pourriez former un brillant de 10 ans pour obtenir le mot de passe et les données en moins d'une heure.
Qu'en est-il des informations d'identification, du mot de passe, etc. d'un utilisateur?
Le tout en clair, avec des outils très simples à disposition pour les tailler.
Accorder le réseau particulier sur lequel on est est également important. Un réseau de bureaux sécurisé est un peu différent d'un salon d'aéroport.
Vrai. Comme je l'ai dit, le FTP est aussi sécurisé que le réseau, et pas plus. C'est aussi une question de modèle de menace. Qui va essayer d'obtenir vos données FTP et pourquoi?
De nos jours, avec sftp et d'autres moyens de transférer des données en toute sécurité, il s'agit plus de savoir pourquoi vous utiliseriez ftp que pourquoi vous utiliseriez les alternatives sécurisées.
Je pense que ce que vous devez garder à l'esprit, c'est que ces types de scénarios ne tendent à augmenter qu'avec le temps. Vous ne vous souciez pas particulièrement des données et ne vous fiez pas à vos informations d'identification, mais ce que vous faites peut se transformer au fil du temps en quelque chose que vous souhaiteriez vraiment avoir passé le temps de bien faire en premier lieu. Beaucoup de professionnels de l'informatique se sont fait dire "ça ne fera que X, et ça ne sera jamais utilisé pour Y" seulement pour que cette même personne revienne 18 mois plus tard et dise "Je sais que j'ai dit que ça ne ferait jamais Y" ... acheter, nous en avons vraiment besoin maintenant. Pouvez-vous le réparer? "
Si vous avez le choix en la matière, ce n'est presque jamais une bonne idée de commencer en insécurité, et supposez simplement "nous ajouterons la sécurité plus tard lorsque nous en aurons besoin". Les alternatives sécurisées ne sont pas vraiment plus difficiles à utiliser et à entretenir, alors pourquoi ne les utiliseriez-vous pas?
Bien que votre question et la réponse de Steffen portent sur la capture de données en transit, de nombreux problèmes liés à FTP ont à voir avec la configuration et l'implémentation côté serveur. De nombreux serveurs FTP (y compris SFTP et FTPS) présentaient de graves vulnérabilités qui permettaient à la fois l'accès en lecture et en écriture aux données. Voici un article de l'année dernière sur la façon dont des centaines de milliers de serveurs FTP sont régulièrement configurés pour un accès anonyme.
Les risques de facilité de mauvaise configuration sont également présents avec les versions sécurisées de FTP. Par exemple, beaucoup de gens ne réalisent pas que les comptes SFTP sont des comptes SSH. Une fois connecté à SFTP, vous pouvez quitter en SSH normal. Si vous n'y avez pas pensé, vous avez peut-être accordé plus d'accès aux utilisateurs SFTP que prévu.
Il existe de nombreux problèmes tels que les attaques de traversée de répertoire qui ne sont pas spécifiques au FTP, mais en raison de la nature de sa conception d'origine et de l'utilisation prévue, ils ont tendance à se présenter plus souvent. Il peut être difficile de trouver des informations et de l'aide pour sécuriser les hôtes FTP en raison de leur obscurité croissante.
C'est pour ces raisons que vous constaterez que de nombreuses normes de sécurité autour de SFTP nécessitent un cryptage séparé des fichiers de données pour empêcher l'exposition de l'accès des données `` au repos ''.