Catégories
Debian planet-libre.org reseau et sécu Ubuntu

Falling back to PORT instead of PASV mode

closeCet article a été publié il y a 11 ans 9 mois , il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Raaah, je me trainais ce truc là depuis longtemps ; pourtant je sais parfaitement que le FTP est un de ces protocoles un peu pourris vis-à-vis des firewalls (et proxies), mais j’avais jamais rien fait pour m’arranger la situation.
Bref, l’occasion de faire un rappel – je passe la théorie car je donnerais dans l’à peu près, mais j’explique l’aspect pratique pour régler le problème titre de cet article.

Lorsque vous avez des problèmes de mode passif, actif etc en FTP, pensez à ceci.
Si quelqu’un veut poster en commentaire la théorie expliquant le problème, n’hésitez pas. Il me semble me rappeler des histoires de trames FTP contenant les IP émettrices et donc nécessité d’avoir des modules de masquerading particulier pour bien gérer le FTP… un vague résidu de cours de réseau 🙂

La configuration

J’ai un serveur avec :

  • un FTP – restreints à certaines IP, rappelez-vous que FTP n’est pas du tout sûr (mot de passe en clair) et qu’il vaut mieux privilégier SFTP (du FTP par dessus SSH),
  • un shorewall ouvrant les ports 20 et 21
  • Bref que du bonheur en apparence.

    Le problème

    Malgré ça, je galère toujours d’un client FTP à l’autre. Le dernier en date : ncftp pour des échanges depuis un LAN vers ce serveur public. Ca se traduit par un cafouilli général dans les modes passifs etc.
    Et un message d’erreur que pour une fois, j’ai relu lentement et me suis rappelé le coup du NAT spécifique FTP :

    Falling back to PORT instead of PASV mode

    En soit, je me foutais de savoir comment le client FTP établissait sa connexion, car dans tous les cas ça marchait, ça restait sécurisé dans la limite de ce que je demandais, mais c’était surtout que la complétion de nom, style cd rep TAB-TAB-TAB mettait 20 secondes à répondre le temps de passer en mode « PORT » justement. Soit environ 19,8 secondes de trop.

    Comment on le règle ?

    On pense à activer le NAT spécifique au protocole FTP, dans netfilter. Pour ce faire, par exemple via l’outil modconf (ou sudo modconf chez Ubuntu) afin d’activer ces 2 modules :
    ./kernel/net/netfilter/nf_conntrack_ftp.ko
    ./kernel/net/ipv4/netfilter/nf_nat_ftp.ko

    Point besoin de rebooter, rien.
    Voilà, un protocole FTP mieux géré par firewall netfilter sur votre serveur.

    Excusez-moi pour l »à peu près technique concernant cet article. FTP ça me gave, c’est un sac d’ennuis ce truc. Mais c’est pratique.

    6 réponses sur « Falling back to PORT instead of PASV mode »

    Euh sinon tu peux aussi faire du sftp ce qui est beaucoup plus simple au niveau firewall.

    Mais d’accord avec toi la multitude de port et l’utilisation de TCP/UDP du protocole FTP rend son suivi difficile.

    ben voui, c’est un peu ce que j’ai écrit
    En attendant, ça reste fondamentalement différent et généralement, les gens sauront faire du FTP et pas nécessairement du SFTP

    Euh pas d’accord, si ce n’est pour la connexion qui a une syntaxe ssh, une fois connecté les commandes ftp sont de rigueurs, put, get, ls, cd, etc

    Mais on est pas pret de se passer du bon vieux ftp 😉

    C’est pas pour rien qu’il y a deux ports dasn le ftp standard …

    Toutes les communications se font en tcp.

    Le premier port est le port de commande. Il est ouvert par le client FTP. En cas de NATage, pas de soucis, donc.

    Le deuxieme est le port data. Et c’est la que les soucis commencent. Il est ouvert par le serveur …

    C’est pour contourner ces soucis que les modules conntrack ont ete ecrits. Mais faut avoir acces au firewall. Et que ce soit un linux.

    Le mode passif fait passer les data dans le canal commande. Pas de soucis, normalement. Mais de la lenteur …

    Evidemment, je ne peut me dispenser du petit RTFM de rigueur : ‘je vous invite a lire le RFC quivabien (il est simple avec pleins de schema ascii).’

    G.

    par ailleurs, je recommande de passer aux solution basees sur ssh (sftp, scp), qui ont plein d’avantages :

    – [deja dit] securite du login/motdepasse
    – on peut faire du transfert serveur1 – serveur2 direct depuis son poste.
    – le flux de donnees lui-meme est crypte. pas d’oreilles indiscretes. si vous voulez sortir les sources du logiciel que vous developpez …
    – par la possibilite de faire simplement des redirections de port. a partir de la seule machine accessible sur le net, on peut acceder aux services d’autres serveurs.

    G.

    Oui bien sûr qu’on ouvre les 2 ports. D’ailleurs avec shorewall un peu récent, la règle s’écrit maintenant :
    FTP/ACCEPT net:une_ip fw
    Et ça ouvre comme il faut le 20 et 21.

    Quand bien même, le mode passif, c’est chiant. Et certains clients FTP tentent l’actif puis le timeout est long avant de passer en passif.
    En n’oubliant pas le module de NAT FTP, on se simplifie la vie

    Laisser un commentaire

    Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

    Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.