Guide des ports FTP : transfert de fichiers sur les ports 20 et 21

FTP sépare les commandes des données de fichiers. Le client se connecte au serveur sur TCP 21, se connecte et envoie des commandes telles que lister, récupérer, stocker, renommer ou supprimer. Les listes de fichiers et les transferts utilisent ensuite une connexion de données distincte.

Cette conception était logique dans les réseaux plus anciens, mais elle crée des problèmes avec le NAT, les pare-feu et les groupes de sécurité cloud. Un vérificateur de port peut indiquer si le port 21 est accessible, mais un transfert de fichier réussi dépend également du canal de données autorisé.

Dans FTP actif, le client se connecte au port de contrôle du serveur, puis le serveur ouvre une connexion de données au client. Cette connexion inversée échoue souvent via le NAT ou des pare-feu clients stricts.

En FTP passif, le client ouvre à la fois la connexion de contrôle et la connexion de données au serveur. Le mode passif est plus courant pour le FTP accessible sur Internet, mais le serveur doit publier une plage de ports passifs définie et les pare-feu doivent autoriser cette plage.

Plain FTP ne crypte pas les noms d'utilisateur, les mots de passe, les commandes ou le contenu des fichiers. FTPS ajoute TLS à FTP, mais il conserve toujours le modèle de contrôle FTP et de canal de données. SFTP est différent : il fonctionne sur SSH, généralement sur TCP 22, et n'utilise pas de ports FTP.

Pour les nouveaux déploiements, SFTP est souvent plus simple à utiliser et à utiliser comme pare-feu. FTPS peut être requis pour la compatibilité des partenaires. Le FTP simple doit être limité aux flux de travail existants isolés ou remplacé lorsque cela est possible.

Ouvrez FTP uniquement lorsqu'un partenaire, un appareil, une application ou un flux de travail existant ne peut pas utiliser SFTP, FTPS, le téléchargement HTTPS, le stockage d'objets ou un service de transfert de fichiers géré. Les exemples courants incluent les anciens flux EDI, les scanners, les appareils intégrés et les intégrations de fournisseurs.

Évitez le FTP public anonyme à moins qu'il ne serve intentionnellement des fichiers publics et qu'il dispose de contrôles de téléchargement stricts. Le FTP inscriptible exposé à Internet est fréquemment utilisé à des fins de mise en scène de logiciels malveillants, de vol de données et d'utilisation abusive du stockage.

Avant d'autoriser FTP, décidez si le serveur utilisera le mode actif, le mode passif ou les deux. Définissez la plage de ports passifs, l'adresse IP externe, le modèle d'isolation des utilisateurs, le comportement chroot ou jail, la journalisation, les quotas et si TLS est requis.

Une vérification TCP sur le port 21 confirme uniquement le chemin de contrôle. Testez les téléchargements réels depuis l'extérieur du réseau, car la plage passive, le NAT, l'inspection TLS et les autorisations du système de fichiers peuvent toujours interrompre les transferts.

Sur Windows Server, IIS FTP peut fournir FTP ou FTPS. Configurez l'isolation des utilisateurs, la politique TLS, la plage de ports passifs, les règles de pare-feu et les paramètres IP externes si le serveur est derrière NAT.

Sous Linux, les serveurs tels que vsftpd, ProFTPD et Pure-FTPd sont courants. Configurez les utilisateurs locaux ou virtuels, le comportement du chroot, la plage de ports passifs, les certificats TLS si vous utilisez FTPS et les règles de pare-feu hôte pour TCP 21 ainsi que les ports de données.

Sur les serveurs cloud, autorisez uniquement les sources requises lorsque cela est possible. Ouvrez TCP 21 et la plage passive dans le groupe de sécurité cloud et le pare-feu hôte. Si vous ne pouvez pas définir une plage passive étroite, FTP sera difficile à sécuriser proprement.

Commencez par une vérification du port externe pour TCP 21. Si le port de contrôle est ouvert, testez avec un vrai client FTP extérieur au réseau. Confirmez la connexion, la liste des répertoires, le téléchargement, le téléchargement, le renommage et la suppression, le cas échéant.

Si la connexion fonctionne mais que la liste des répertoires ou les transferts se bloquent, inspectez les paramètres du mode passif, la plage de ports passifs, la publicité IP externe, le NAT, les groupes de sécurité cloud et les paramètres TLS. De nombreux échecs FTP sont des échecs du canal de données et non du port 21.

Si le port 21 est fermé, le service FTP peut être arrêté, lié à une interface privée, bloqué par un pare-feu hôte ou refusé par un groupe de sécurité cloud. Si le port 21 est ouvert mais que les transferts échouent, les ports passifs ou NAT sont les premiers endroits à vérifier.

Si l'authentification échoue, inspectez le format du nom d'utilisateur, la politique de mot de passe, le verrouillage du compte, les autorisations chroot, la propriété du système de fichiers, les exigences TLS et les journaux du serveur. Si seuls certains clients échouent, comparez le mode actif et passif et déterminez si le client est derrière un NAT restrictif.

Évitez le FTP simple pour les informations d'identification ou les fichiers privés. Utilisez FTPS ou SFTP lorsque cela est possible, désactivez le téléchargement anonyme, restreignez les adresses IP sources, isolez les utilisateurs, définissez des quotas et conservez des journaux de transfert détaillés.

Si FTP doit rester public, corrigez le serveur, limitez les ports passifs, surveillez les échecs de connexion et le volume de téléchargement, analysez les fichiers téléchargés et supprimez les comptes obsolètes. Traitez FTP comme une exception héritée avec un propriétaire et un plan de migration.