Voici ce que disent les données : la majorité des dysfonctionnements FTP que je diagnostique en PME ne viennent pas du serveur FTP lui-même, mais d’une mauvaise compréhension des ports impliqués, en particulier en mode passif derrière un pare-feu ou une box NAT.
Les ports FTP, en clair
Le protocole FTP utilise deux canaux distincts : un canal de commande et un canal de données. Le canal de commande utilise systématiquement le port 21. Le canal de données dépend du mode utilisé :
- Mode actif : le serveur initie la connexion de données vers le client depuis son port 20. Ce mode fonctionne mal derrière un pare-feu côté client, puisque celui-ci doit accepter une connexion entrante non sollicitée.
- Mode passif : le client initie les deux connexions. Le serveur annonce un port dans une plage définie (par exemple 50000-51000) sur lequel le client se connecte pour les données. C’est le mode recommandé aujourd’hui, mais il exige d’ouvrir toute la plage passive sur le pare-feu du serveur, pas seulement le port 21.
Configuration côté serveur (vsftpd)
Sur un serveur Debian avec vsftpd, la configuration passive minimale dans /etc/vsftpd.conf :
pasv_enable=YES
pasv_min_port=50000
pasv_max_port=51000
pasv_address=IP_PUBLIQUE_DU_SERVEURLe paramètre pasv_address est celui que j’oublie de vérifier le moins souvent, et pourtant c’est la cause la plus fréquente d’échec derrière un NAT : sans lui, le serveur annonce son adresse IP interne au client, qui tente alors de s’y connecter en vain depuis l’extérieur.
Le cas rencontré
Une PME de Rennes m’a signalé des transferts qui se bloquaient systématiquement après l’authentification, sans message d’erreur clair côté client. Le pare-feu n’autorisait que le port 21 en entrée ; la plage passive complète (1000 ports dans leur configuration) n’était pas ouverte. Le client listait bien le contenu du dossier — cette opération passe par le canal de commande — mais tout transfert réel échouait, puisqu’il dépendait du canal de données bloqué.
Une mise en garde importante : ouvrir 1000 ports sur un pare-feu de production augmente la surface d’exposition. Réduire la plage passive au strict nécessaire (une centaine de ports suffit généralement pour une PME avec quelques transferts simultanés) limite ce risque sans casser le fonctionnement.
FTP vs SFTP : une nuance nécessaire
Attention, beaucoup confondent FTP et SFTP. Le FTP classique transmet les identifiants en clair sur le réseau, y compris en mode passif. SFTP (SSH File Transfer Protocol) chiffre l’intégralité de l’échange et n’utilise qu’un seul port (22, celui de SSH), ce qui simplifie d’ailleurs la configuration pare-feu. Pour tout transfert impliquant des données sensibles, SFTP est la seule option raisonnable en 2026 ; FTP classique ne devrait plus servir que pour des cas très spécifiques sur réseau interne isolé.
Vérification rapide
Pour tester la plage passive depuis l’extérieur sans dépendre d’un client FTP complet :
nc -zv IP_SERVEUR 50000-51000Cette commande teste rapidement si les ports de la plage répondent, ce qui isole immédiatement un problème de pare-feu d’un problème de configuration serveur.
Le cas des clients FTP grand public mal configurés
Une source d’erreurs que je rencontre régulièrement, indépendamment du serveur : certains clients FTP grand public (FileZilla en tête, très répandu en PME) conservent en mémoire un mode de connexion (actif ou passif) configuré une fois puis jamais revérifié, y compris après un changement d’infrastructure réseau côté client. Un poste qui fonctionnait très bien avant un changement de box internet peut se retrouver bloqué simplement parce que le mode actif, qui passait par l’ancienne box, ne passe plus par la nouvelle. Vérifier explicitement le mode configuré dans le client, plutôt que de supposer qu’il est resté correct, fait partie de mon premier réflexe de diagnostic.
Journalisation : ce qui aide vraiment au diagnostic
Sur vsftpd, activer une journalisation détaillée facilite énormément le diagnostic des cas ambigus :
xferlog_enable=YES
xferlog_std_format=NO
log_ftp_protocol=YESAvec log_ftp_protocol activé, le journal enregistre l’intégralité du dialogue de commandes FTP, ce qui permet de voir précisément à quelle étape un client échoue — authentification, listing, ou ouverture du canal de données. Sans cette journalisation détaillée, le diagnostic repose uniquement sur les messages d’erreur côté client, souvent trop génériques pour identifier la cause réelle.
À retenir pour votre projet
Si un transfert FTP bloque après authentification, vérifiez d’abord la plage passive et le paramètre d’adresse annoncée avant de chercher ailleurs. Et posez-vous la question : ce transfert a-t-il vraiment besoin de FTP classique, ou SFTP conviendrait-il tout aussi bien avec une configuration plus simple et plus sûre ?
Firewall applicatif et fail2ban
Un serveur FTP exposé, même correctement configuré, reste une cible pour des tentatives de connexion automatisées. Ajouter fail2ban avec un filtre dédié à vsftpd bannit automatiquement les adresses IP après un nombre défini de tentatives d’authentification échouées, réduisant significativement le volume de tentatives de force brute sans intervention manuelle :
sudo apt install fail2ban
sudo nano /etc/fail2ban/jail.localAvec une configuration minimale activant le filtre vsftpd sur le fichier de log approprié, ce dispositif tourne en arrière-plan sans configuration supplémentaire une fois en place, et j’en fais une recommandation systématique pour tout service exposé directement sur internet, FTP ou non.
Le cas des box internet grand public
Pour les très petites structures qui hébergent un serveur FTP directement derrière une box internet grand public plutôt qu’un serveur dédié en datacenter, la redirection de port côté box ajoute une couche de configuration supplémentaire à ne pas oublier : il faut rediriger non seulement le port 21, mais l’intégralité de la plage passive définie dans vsftpd.conf, faute de quoi la configuration serveur peut être parfaitement correcte sans que rien ne fonctionne de l’extérieur. C’est une source d’erreur fréquente que j’ai rencontrée précisément dans ce contexte : la configuration logicielle était irréprochable, mais la box elle-même ne redirigeait que le port de commande.
Pour aller plus loin
Pour une référence externe, consultez les recommandations de l’ANSSI sur la sécurité des transferts de fichiers.