Où la protection du VPN s’arrête sur le chemin d’un serveur FTP

Un VPN protège un chemin, et un chemin a une fin. Quand le tunnel se termine à une passerelle d’entreprise, le transfert de fichiers continue de là sous la protection que fournit son propre protocole. Cette distinction décide si un transfert est protégé de bout en bout ou seulement jusqu’à la passerelle. L’indicateur Connected ne dit rien de l’un ni de l’autre.

Deux emplacements, deux chemins restants

Prenez un ordinateur portable qui rejoint le VPN de l’entreprise puis ouvre une session FTP vers un serveur interne distinct. Le tunnel s’arrête à la passerelle, et le segment entre la passerelle et ce serveur se trouve en dehors.

Le FTP simple n’acquiert pas de chiffrement parce que ses paquets sont arrivés par un tunnel. Sur ce segment restant, les commandes, les identifiants et le contenu des fichiers circulent exactement comme le protocole le définit, c’est-à-dire en clair. L’importance de ce point dépend de la topologie et de ce qui protège aussi ce segment, et qualifier l’adresse de privée ne répond pas à la question. Le même raisonnement vaut à l’inverse quand le serveur vit dans un réseau cloud que la passerelle atteint par un autre saut.

Placez le point de terminaison du VPN et le service FTP sur une seule machine et il n’y a plus de segment suivant à craindre. C’est un autre emplacement, non une preuve que les processus, les fichiers et les identifiants de l’hôte sont sûrs.

FTP simple, FTPS et SFTP sont trois décisions

Le FTP simple ne chiffre rien, pas même le mot de passe. FTPS ajoute TLS à FTP, de sorte que le canal de contrôle et, lorsqu’il est négocié, le canal de données sont protégés. SFTP est un protocole différent transporté à l’intérieur de SSH, et ce n’est pas une autre orthographe de FTPS.

Le serveur doit prendre en charge ce choix, car un client ne peut pas inventer un écouteur qui n’existe pas. Choisir SFTP ne transforme pas un service uniquement FTP en point de terminaison SSH, et renommer un favori ou changer un port ne prouve rien sur ce qui a été négocié. Confirmez le protocole du côté du serveur comme du côté du client. Un cadenas dans un gestionnaire de fichiers est une affirmation sur la session, non sur l’écouteur derrière elle.

Lisez la dernière colonne quand le transfert compte, car c’est là qu’apparaît un changement d’identité inattendu.

La connexion de données est une seconde connexion

FTP ouvre une connexion de contrôle puis des connexions de données distinctes pour les listages et les transferts. Une connexion protégée ne dit rien de ces connexions ultérieures, sauf si le déploiement exige aussi leur protection.

Avec FTPS, le client demande un canal de données protégé par une commande précise, et une politique du serveur peut refuser l’alternative en clair. Vérifiez que la politique l’exige au lieu de supposer que la valeur par défaut du client suffit. Le mode passif ajoute une seconde complication, car le serveur annonce une adresse et un port pour la connexion de données. Un pare-feu ou un dispositif NAT qui réécrit ou bloque cette annonce produit une session qui s’authentifie puis se bloque au premier listage.

curl -vk ftps://files.corp.example/ --user alice --ftp-ssl-control
openssl s_client -connect files.corp.example:21 -starttls ftp
ss -tnp | grep -E ':21|:990'

La deuxième commande montre ce que le serveur présente sur le canal de contrôle avant de toucher au moindre fichier. La troisième montre si une connexion de données a jamais été établie, ce qui fait la différence entre un échec d’authentification et un échec du mode passif.

Les contrôles d’identité survivent au tunnel

Un client FTPS valide l’identité d’un serveur TLS, et un client SFTP valide une clé d’hôte SSH. Les deux contrôles relèvent du protocole de transfert de fichiers, et aucun n’est effectué par le VPN.

Cette séparation compte quand quelque chose au milieu veut inspecter la session. Désactiver TLS pour qu’un équipement réseau puisse lire les commandes change le modèle de protection au lieu de le compléter, et il en va de même pour l’acceptation d’une clé d’hôte inexpliquée parce que le tunnel est monté. Conservez la configuration de confiance prévue et obtenez le bon matériel auprès de l’exploitant. Un tunnel qui s’authentifie ne dit rien du serveur à son extrémité distante.

Le matériel de clé privée et de certificat pour ces protocoles est encore un troisième secret, distinct de l’identifiant du VPN.

Notez ce que vous avez réellement vérifié

Choisissez un fichier inoffensif que vous êtes autorisé à déplacer et notez quatre faits sur la tentative : quel protocole a tourné, quelle identité du pair a été vérifiée, quel chemin était prévu et si le transfert a abouti.

lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]

Un listage de répertoire, une connexion au tunnel et un transfert terminé sont trois observations distinctes, et seule la dernière dit que le chemin fonctionne pour les fichiers. Si la conception ne compte que sur le VPN pour la confidentialité sur le saut restant, écrivez-le comme la décision qu’il est. Une note d’acceptation nommant le saut et son hypothèse de confiance vaut mieux qu’une capture d’écran d’un client connecté.