[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ftp : xxbox et suivi de connexion



On Wed, Jun 20, 2007 at 01:37:43AM +0200, Pascal Hambourg wrote:
> Franck Joncourt a écrit :
> >>
> >Oui c'est ça, sauf que je ne savais pas quelle adresse il mettait dans
> >la réponse à une requête pasv si je ne définissais pas celle-ci
> >explicitement.
> 
> Normalement il devrait mettre l'adresse avec laquelle il répond, qui est 
> l'adresse sur laquelle il a reçu la connection de contrôle du client.
>

Je verrais, ce n'est pas dificile à mettre en évidence de toute façon.

> [...]
> >>Une solution simple consisterait à autoriser l'état NEW en entrée pour 
> >>les ports passifs. Mais je pense que tu le savais déjà.
> >
> >Oui, mais cela me déplait un peu.
> 
> Sinon, j'avais aussi pensé à charger le module de suivi de connection 
> FTP ip_conntrack_ftp ou nf_conntrack_ftp avec l'option loose=1. Je ne 
> suis pas certain du rôle de cette option, peut-être que c'est plutôt 
> pour le FXP (transfert de serveur à serveur), mais ça ne te coûte pas 
> grand chose d'essayer. Moi je n'ai pas trop le temps de monter une manip 
> pour tester, mais retour bienvenu.
> 

J'essaierais aussi et je te dirais ce qu'il en est.

> >Qu'entends tu par translation de l'adresse en mode passif ?
> 
> La translation de l'adresse transmise par le serveur dans la réponse à 
> la commande PASV afin qu'elle corresponde à l'adresse source du paquet. 
> Il est assez courant que les routeurs NAT fassent cette translation dans 
> les commandes PORT afin que les transferts FTP en mode actif initiés 
> depuis un client masqué passent. Or l'opération est quasiment la même 
> dans les deux cas.
> 

Malheureusement, elle n'a pas l'air de faire cela. En espionnant les
trames du côté client, je vois bien que le client tente d'effectuer la
connexion sur le data channel, en fonction de l'adresse placée dans la
réponse à la commande PASV. Et donc, si mon option pasv_address est
192.168.1.10 alors le client recoit l'ip 192.168.1.10 et tente d'établir
la connexion avec 192.168.1.10 et non plus sur mon adresse publique.
Comme la requete doit passer via Internet, elle se perd en chemin.
C'est ce que je tente d'expliquer dans le cas 1 ci dessous.

Si l'option pasv_address contient mon ip publique, alors c'est le cas 2.


> >Donc d'après ce que je comprends, deux cas se présentent (dans tous les
> >cas le dialogue sur le control channel se passe bien)
> >
> > 1/ cas 1: la réponse du serveur FTP, au client extérieur, à la commande
> > PASV contient l'adresse local, et le port de connexion sur lequel le
> > serveur est à l'écoute. La xxbox se charge de modifier les en-tête
> > des trames ip pour la prise en compte de l'adresse publique. Le client
> > tente de se connecter alors sur le data channel mais échoue à cause de
> > l'ip destination qui est l'ip local du serveur. La solution serait que
> > la xxbox modifie l'ip présente dans la réponse à la commande PASV (ip
> > locale du serveur) par l'ip publique.
> 
> Oui, comme toute box basée sur un noyau Linux avec Netfilter et les 
> modules de suivi de connexion et NAT pour FTP le ferait.
> 
> > => Il n'y a aucune chance que ce soit possible. Dans ce cas, le suivi
> > de connexion aurait fonctionné.
> 
> Comment ça ?

Ca ne fonctionne pas chez moi, comme je le précise dans ce mail un peu
plus haut.

> 
> > 2/ cas 2 : celui que je rencontre et que tu as expliqué ci-dessus.
> > Le suivi de connexion ne fonctionne pas.
> >
> >Au final, il n'y a pas d'issue hormis d'autoriser les connexions de
> >types NEW sur les ports passifs du serveur.
> 
> En fait il y en a une troisième : ne pas utiliser le mode passif 
> classique (PASV) mais le mode passif étendu (EPSV) qui ne transmet que 
> le port et pas l'adresse (redondante puisque c'est forcément l'adresse 
> du serveur). Cela suppose d'utiliser uniquement un serveur FTP et des 
> clients FTP qui le supportent.
> 

Cela m'a l'air bien ça (EPSV), je vais aussi regarder ça.

et refaire mes manips car j'ai forcément loupé quelque chose.

-- 
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

Attachment: signature.asc
Description: Digital signature


Reply to: