SCP est-il dangereux? Devrait-il être remplacé par SFTP?

Question

J'ai plus de 20 ans d'expérience dans UN * X et j'utilise scp pour les temps immémoriaux. scpis sur ssh, donc je le considère comme aussi sûr que ce dernier. Maintenant, dans ma société, où j'ai récemment pris un emploi, l'agent de sécurité dit que scp ne doit pas être utilisé, car il est dangereux et obsolète. sftp devrait être favorisé dessus (encore sur ssh aussi ...)

Je ne suis pas immédiatement d'accord avec cela, sur la base de l'infrastructure sous SCP, et sur la base de la popularité et de la confiance scp est dans la communauté professionnelle et parmi mes autres collègues de mes ex-sociétés. Je ne veux pas changer d'avis juste parce que certains CSO l'ont dit.

Cela dit, y a-t-il ici un sujet?
Est scp soudainement le Blacksheep?
Est-ce que vient de simples débats d'experts en matière de sécurité dans des sphères supérieures?
Ou est scp juste bon à utiliser?

JoL · Answer

C'est marginalement "dangereux"

IT était marginalement "dangereux" avant l'addition de scp -T à OpenSSH 8.0 et c'est toujours est Marginalement "dangereux" lors de l'utilisation scp -r.

Comme d'autres réponses ont déclaré, affirme que SCP est dangereuse provenant de l'incapacité du client pour vérifier qu'il reçoit ce qu'il a demandé. La raison pour laquelle SCP ne pouvait pas vérifier est que la demande est faite à l'aide du code Shell exécutant dans l'environnement du serveur (avec l'état du serveur).

Par exemple, disons que la coquille du serveur est définie sur ZSH avec GLOB étendu et j'ai mes répertoires de projet définis comme des répertoires nommés ZSH dynamique pour un accès rapide. Si je veux obtenir un fichier de Rails Project FOO, je pourrais l'obtenir avec:

scp server:~foo/config/database.yml .

zSH sur mon serveur se développe ~foo à ~/work-for/client/$client_name/foo.

Si je veux obtenir les 10 derniers fichiers réguliers du serveur, je pourrais faire:

scp server:'*(.oc[1,10])' .

Si le serveur a une simple bash, je pouvais faire:

scp server:'$(ls -t | head -10)' .

Si je voulais obtenir les fichiers qui contenaient un modèle foo dans leur contenu, je pourrais faire:

scp server:'$(grep -l foo *)' .

Il n'ya tout simplement aucun moyen pour le client SCP de vérifier ces types de demandes qui utilisent le code Shell. Cependant, c'est une préoccupation qu'il permet à un serveur malveillant de répondre à:

scp -r server:foo/ ~

avec écrasement .ssh/authorized_keys. Aux yeux de scp, foo/ est le code shell de serveur qui évaluera à qui sait quoi.

Entrer scp -T:

- T Désactiver la vérification du nom de fichier strict. Par défaut lors de la copie des fichiers d'un hôte distant à un répertoire local SCP vérifie que les noms de fichiers reçus correspondent à ceux demandés sur la ligne de commande afin d'empêcher la fin distante d'envoyer des fichiers inattendus ou indésirables. En raison de différences dans la manière dont divers systèmes d'exploitation et shells interprètent les caractères génériques du nom de fichier, ces chèques peuvent provoquer la rejetation des fichiers souhaités. Cette option désactive ces chèques au détriment de la confiance intégrante que le serveur n'enverra pas de noms de fichiers inattendus.

Pour résumer, le comportement par défaut précédent de scp a été déplacé vers -T, et maintenant la valeur par défaut consiste à vérifier ce qui est reçu, à l'aide de l'argument fourni comme un modèle simple, quand on ne fait pas une copie récursive. Je crois qu'il reconnaît des globs et des échappés simples ( regarder la source , il utilise Fnmatch (3) pour la correspondance, avec des indicateurs définis sur 0). En d'autres termes, il se comporte plus de manière prévisible lorsque vous ne souhaitez pas profiter de sa capacité unique à spécifier des fichiers par code shell.

Alors maintenant, si vous n'utilisez pas -T Et vous n'utilisez pas -r, le seul moyen d'écraser des choses comme .bashrc est de demander cela explicitement. Si vous souhaitez utiliser du code shell, vous devez utiliser -T au détriment de la confiance du serveur:

scp -T server:'*(.oc[1,10])' .

Alors maintenant, vous obtenez la sécurité dans les cas simples et non récursifs sans abandonner complètement la capacité unique qui fait scp plus utile que les autres utilitaires tels que sftp ou rsync.

Can SCP être remplacé par SFTP?

sFTP ne peut pas spécifier les fichiers qu'il souhaite avec code shell. Cela n'accepte que les chemins de fichiers réels. C'est plus limité de cette façon. Si vous n'aviez besoin que de SCP pour de simples filechas, alors oui. Toutefois, si vous souhaitez que la puissance ajoutée de pouvoir spécifier les fichiers d'une commande simple avec un code shell côté serveur (bien que, à la charge de devoir faire confiance à votre serveur), je pense que votre seul choix est scp.

Pourquoi les citations autour de "dangereux"?

C'était dangereux, mais seulement lorsque vous ne faites pas confiance au serveur pour ne pas être compromis. Dans mon cas, et peut-être pour la majorité des personnes, nous utilisons SCP avec des serveurs que nous avons complètement confiance en d'autres moyens de toute façon. En particulier, je l'utilise pour vous connecter à mon ordinateur portable à mon bureau ou vice versa. Si nous ne pouvons pas faire confiance à nos propres appareils, que pouvons-nous faire confiance? C'est pourquoi je pense que l'appeler simplement dangereux est hyperbolique. Ce n'est pas comparable à la manière dont nous appelons Telnet dangereux, par exemple.

J'apprécie toujours le changement pour exiger -T, bien que. IT est plus sûr. En outre, il est certainement vrai que pour les personnes qui n'ont pas besoin des fonctionnalités activées par -T, il n'y a vraiment pas beaucoup d'avantage pour utiliser SCP sur SFTP ou RSYNC.

Archemar · Answer

La façon dont je lis c'est, "cela dépend".

Selon - CVE-2019-6111

Toutefois, le client SCP n'effectue que la validation curseure du nom d'objet renvoyé (seules les attaques traversées de répertoire sont évitées). Un serveur SCP malveillant (ou un attaquant man-in-the-intermédiaire) peut remplacer les fichiers arbitraires dans le répertoire cible du client SCP. Si l'opération récursive (-R) est effectuée, le serveur peut également manipuler les sous-répertoires (par exemple, pour écraser le fichier .SSH/Authorized_Keys).

Donc, si scp passe entre les hôtes de vos locaux (Datacenter), il est probable (mais pas certain) que aucune attaque MITM ne peut être effectuée.

Toutefois, si vous récupérez des fichiers commerciaux d'un client/partenaire sur le Web World Wild Web, vous devez compter sur sftp ou mieux, ftps. (Au moins, assurez-vous que le client scp et ssh serveur dispose de versions appropriées)

Dmitry Grigoryev · Answer

Je dirais que beaucoup de commandes UNIX deviennent dangereuses si vous envisagez un MITM sur SSH possible. Un Sudo pourrait voler votre mot de passe, un client de communication malveillant pourrait lire vos mails/messages instantanés, etc.

Dire que le remplacement scp avec sftp Lorsque vous parlez à un serveur compromis, corrigera en quelque sorte la situation est très optimiste pour le moins. Quel que soit le dommage scp peut faire à vos fichiers locaux peut également être effectué à partir d'un fichier binaire, d'un script shell, Python fichier, maquillage, etc., et un voyou sftp va vous servir heureux ces.

En bref, si vous ne faites pas attention auxquels vous ne faites pas attention aux serveurs SSH, il y a un risque élevé que vous soyez vissé, quel que soit les outils que vous utilisez et utilisez sftp au lieu de scp Soyez seulement marginalement plus sûr.

Cela ne veut pas dire que la commutation à sftp est une mauvaise idée: s'il s'agit d'un outil supérieur pour la tâche à accomplir, vous avez une bonne raison de changer, ce qui est d'ailleurs non lié à la sécurité.

mosvy · Answer

Il y a beaucoup de confusion sur le nouveau OpenSSH changements à scp fait en réponse à CVE-2019-6111 , et quelle sécurité ils sont censés faire tout.

Leur objectif est d'empêcher un serveur de voyous utilisé comme source pour les fichiers d'envoyer d'autres noms de fichiers que demandé et écrasez des fichiers aléatoires sur la machine locale.

Mais ils n'ont aucun effet lorsque l'option -r est utilisée . Utiliser -r implique -T.

Bien que parfaitement logique, beaucoup de gens ne manqueraient pas de le réaliser, et ils seront bercés dans un sens de la complaisance en s'attendant toujours à scp pour vérifier les noms de fichiers. Jusqu'à ce qu'ils rencontrent la dure vérité, un jour. La "sécurité" offerte par cela n'est pas meilleure que alias rm='rm -i'.

Comme il peut être assez convolué pour configurer un serveur Rogue SSH/SCP uniquement pour tester, vous pouvez utiliser l'option -S program de scp (qui le dirige pour utiliser un autre programme que ssh pour configurer la chaîne) pour vérifier ma réclamation.

Ici, j'utilise un petit script exécutable ssh_from_hell, qui, peu importe ce qui est demandé, envoie toujours un fichier lolcats.lol:

$ chmod 755 ssh_from_hell $ scp -S ./ssh_from_hell user@Host:foo.txt . protocol error: filename does not match request # OK, as expected $ scp -S ./ssh_from_hell -r user@Host:foo/ . lolcats.lol 100% 12 62.0KB/s 00:00 $ cat lolcats.lol LOL LOL LOL $ cat ssh_from_hell #! /usr/bin/Perl use strict; $|=1; # autoflush sub readack { local $/=\1; <STDIN> } sub ack { print "\0" } my $data = join '', <DATA>; readack; printf "C%04o %lld %s
", 0666, length($data), "lolcats.lol"; readack; print $data; ack; __DATA__ LOL LOL LOL

Un autre incarcicité à propos de la nouvelle modification est le fait que vous ne pouvez plus citation Le nom de fichier distant, au lieu de

scp 'user@Host:"a file with spaces and * love *.txt"' .

tu devrais utiliser

scp 'user@Host:a\ file\ with\ spaces\ and\ \*\ love\ \*.txt' .

Cependant, certains développeurs influents aiment apparemment des accolades, ils ont donc également ajouté une mise en oeuvre de correspondance de motif ad-hoc avec support d'accolades à scp - ils auraient pu probablement utiliser glob(3) avec GLOB_ALTDIRFUNC|GLOB_BRACE, mais il est toujours plus amusant d'écrire un nouveau code. Quoi qu'il en soit et Fwiw, remarquez que la mise en œuvre de l'expansion BRACE dans SCP est presque-like-like-IE. {{foo}} va s'étendre à foo:

$ scp -S ./ssh_from_hell 'user@Host:{{lolcats.lol}}' . lolcats.lol 100% 12 61.6KB/s 00:00

Pourtant, pas exactement la même chose que celle de csh, Perl et glob(3):

$ scp -S ./ssh_from_hell 'user@Host:lolcats{}.lol' . protocol error: filename does not match request

Et aussi buggy:

$ scp -S ./ssh_from_hell 'user@Host:lolcats{,}.lol' . protocol error: filename does not match request

ron · Answer

Man SCP

sCP copie des fichiers entre hôtes sur un réseau. Il utilise SSH (1) pour le transfert de données et utilise la même authentification et fournit la même sécurité que SSH (1). Contrairement à la RCP (1), SCP demandera des mots de passe ou des phraséphrases s'ils sont nécessaires à l'authentification.

Vous avez demandé est SCP dangereux? Cela peut être, tout comme n'importe quoi d'autre non configuré et utilisé correctement.

Homme au milieu (MITM) Vulnérabilité, vous savez que la popup initiale vous obtenez la première fois à quelque part, celle que vous ignorez et cliquez simplement sur OK sur ...

la clé d'hôte du serveur n'est pas mise en cache dans le registre. Vous n'avez aucune garantie que le serveur est l'ordinateur que vous pensez que c'est. L'empreinte digitale SSH du serveur est blanchabla.

Ce n'est pas une faute de SSH (ou SCP). Il est à vous de ne pas utiliser correctement le protocole.

Une fois que vous avez établi le serveur SSH, votre connexion est celle qui est censée être, alors c'est une simple question de (à mon avis) de en utilisant le protocole SSH 2 et les ciphères AES-256. C'est la majeure partie de votre sécurité; Si vous n'alisez pas votre sshd_conf (et le client ssh_config) et laissez-le défaut, alors c'est sur vous.

voici un excepté d'un sshd_config que vous pouvez méditer sur

Protocol 2 Ciphers aes256-ctr MACs hmac-sha2-512,hmac-sha2-256 # MACs hmac-sha1 PermitRootLogin no AuthorizedKeysFile .ssh/authorized_keys {set this up} IgnoreRhosts yes IgnoreUserKnownHosts yes StrictModes yes UsePAM yes

selon CVE-2019-6111

le client SCP n'effectue que la validation curseure du nom d'objet renvoyé (seules les attaques de trafiquant de répertoires sont évitées). Un serveur SCP malveillant (ou un attaquant man-in-the-intermédiaire) peut remplacer les fichiers arbitraires dans le répertoire cible du client SCP. Si l'opération récursive (-R) est effectuée, le serveur peut également manipuler les sous-répertoires (par exemple, pour écraser le fichier .SSH/Authorized_Keys).

qui est sorti du contexte. Ne vous connectez pas à un serveur SSH malveillant en premier lieu. Ne blâmez pas SSH pour que quelqu'un exploite le protocole Configuration de leur serveur SSH sur Remplacez des fichiers arbitraires dans le répertoire cible du client SCP. Utilisation des touches serveur/client pour établir correctement la connexion SSH la première place et il n'y a pas de serveur malveillant mitm.

sCP, qui est SSH, est sûr. Dire SCP n'est pas sécurisé, disant ssh ne devrait pas être utilisé car SSH est dangereux et ce n'est pas vrai.

Ssh = coquille sécurisée

sCP = copie sécurisée sur ssh

fTP = Protocole de transfert de fichier

sftp = ssh ftp

fTPS = FTP sur TLS/SSL

SCP doit-il être remplacé par SFTP ?

lorsque vous ne pouvez pas être dérangé par la touche hôte/empreinte digitale du serveur et cliquez simplement sur OK, demandez-vous comment alors est-ce correct avec SFTP (connexion à un serveur que vous n'avez aucune garantie est qui vous le pensez).

une fois que la communication SSH tunnel est établie entre deux points, correctement, la sémantique de la communication dans l'intérieur est une copie sécurisée ou le protocole de transfert de fichier est trivial à ce moment-là. SCP, qui est SSH, est sûr. Selon SCP, SCP n'est pas sécuritaire, dit SSH ne devrait pas être utilisé car SSH est dangereux. Et ce n'est pas vrai. Si je vous appelle au téléphone et que vous causez de mauvaises choses à ma fin, ce n'est pas la faute de la compagnie de téléphone.

"Le protocole SCP est obsolète, inflexible et non facilement corrigé. Nous recommandons l'utilisation de protocoles plus modernes tels que SFTP et RSYNC pour le transfert de fichier à la place."

pleeeasssee .... rsync n'effectue aucun cryptage seul et vous rencontrez dans le même problème de ne pas avoir de garantie que vous vous connectez à qui vous pensez. Mais dans cette insinuation, rsync reçoit une passe? Prudent d'où vous prenez des recommandations de.