Si vous avez réellement besoin d'utiliser FTP (sans l'emballer avec sslwrap ou à l'intérieur d'un tunnel SSL ou SSH), vous devriez « chrooter » FTP dans le répertoire personnel de l'utilisateur, ainsi l'utilisateur ne pourra rien voir d'autre que ses propres répertoires. Autrement, il pourrait parcourir le système comme s'il disposait d'un interpréteur de commandes. Vous pouvez ajouter la ligne suivante dans la section global de proftpd.conf pour activer ce chroot :

DefaultRoot ~

Redémarrez ProFTPD par /etc/init.d/proftpd restart et vérifiez si vous pouvez sortir de votre propre répertoire personnel.

Pour prévenir ProFTPD d'attaques par déni de service avec l'utilisation de ../../.., ajoutez la ligne suivante dans /etc/proftpd.conf : DenyFilter \*.*/

Rappelez-vous toujours que FTP envoie les identifiants et les mots de passe d'authentification en clair (ce n'est pas un problème si vous fournissez un service public anonyme) et il existe de meilleures alternatives dans Debian pour cela. Par exemple, sftp (fourni par ssh). Il existe également d'autres implémentations de SSH pour d'autres systèmes d'exploitation : http://www.chiark.greenend.org.uk/~sgtatham/putty/ et http://www.cygwin.com par exemple.

Cependant, si vous maintenez encore le serveur FTP tout en donnant un accès par SSH aux utilisateurs, vous pouvez rencontrer un problème courant. Les utilisateurs accédant aux serveurs FTP anonymes à l'intérieur des systèmes sécurisés par SSH peuvent essayer de se connecter dans le serveur FTP. Bien que l'accès sera refusé, le mot de passe sera tout de même envoyé en clair sur le réseau. Pour éviter cela, le développeur de ProFTPD, TJ Saunders, a créé un correctif pour empêcher des utilisateurs de fournir au serveur FTP anonyme des comptes SSH valables. Plus d'informations et le correctif sont disponibles, consultez http://www.castaglia.org/proftpd/#Patches. Ce correctif a été également indiqué pour Debian, consultez le http://bugs.debian.org/145669.