Serveur ftp et NAPT

geo cherchetout , dans le message
<4ddb7a36$0$14688$ba4acef3@reader.news.orange.fr>, a écrit :

Qu'en dîtes vous ?

Que le FTP est un protocole de merde et qu'il commencerait à être temps de
le laisser crever.

Fais du SFTP, tu n'auras pas de problèmes.

Le 24/05/2011 11:28, geo cherchetout a écrit :

Bonjour,

Pour des échanges de documents avec quelques correspondants, j'ai installé
pure-ftpd sur mon pc. J'ai créé les utilisateurs virtuels en suivant les
indications de Léa :
http://www.lea-linux.org/documentations/index.php/Reseau-partfic-pureftpd
En local, tout fonctionne parfaitement. (Client en mode actif.)
Malheureusement, plusieurs correspondants se plaignent de ne pouvoir se
connecter ou, plus exactement, de ne pas obtenir la liste des fichiers de
leur répertoire. Je me demande donc si les règles de NAT que j'ai créées
dans mon modem-routeur sont correctes. Tel que je l'ai configuré, le serveur
propose pour les données un port dans la plage 30000-30199. (Mode passif)
Règle NAT créée au bénéfice de mon poste dont l'ip locale est fixe :

Protocol Port_Range Translate_to Trigger_Protocol Trigger_Port
**************************************************************************
TCP 21-21 21-21
TCP 30000-30199 30000-30199 TCP 21

Qu'en dîtes vous ?

Bonjour,

Si vous autorisez les connexions sortantes (nécessaires à
l'établissement d'une connexion de données en mode actif sur votre
serveur FTP), votre configuration semble correcte, mais certains de vos
correspondants sont peut-être situés derrière des
routeurs/firewalls/autre qui ne comprennent pas le protocole FTP, ce qui
empêche un fonctionnement correct du mode actif: en effet si le client
FTP de votre correspondant utilise ce mode, la commande "PORT" qu'il
enverra à votre serveur inclura son adresse IP *privée*, celle utilisée
sur son LAN, et qui est inaccessible à votre serveur.

Pour que cela fonctionne correctement, il faut que le routeur, la box,
ou de manière plus générale l'équipement qui connecte le client
problématique à Internet comprenne le protocole FTP et sache le
décortiquer afin de remplacer à la volée, dans la commande "PORT",
l'adresse IP privée de la machine cliente sur le LAN, par l'adresse
publique du routeur (avec un éventuel changement de port à la clef si
c'est nécessaire).

C'est la raison la plus probable, à mon avis, de ce mauvais
fonctionnement, mais malheureusement, vous n'y pouvez pas grand-chose, à
part conseiller à vos interlocuteurs de passer en mode passif...

Cela dit, je suis assez d'accord avec le commentaire de Nicolas George
sur le côté un peu obsolète, désormais, du protocole FTP, qui peut
avantageusement être remplacé par SFTP ou autre chose. Mais bon, il est
évident qu'une telle décision ne peut se faire que si tous vos
correspondants sont à même d'utiliser le nouveau protocole...

Cordialement,

--
Bruno Tréguier

Le 24/05/2011 15:17, *Bruno Tréguier* a écrit fort à propos :

Bonjour,

Si vous autorisez les connexions sortantes (nécessaires à
l'établissement d'une connexion de données en mode actif sur votre
serveur FTP), votre configuration semble correcte, mais certains de vos
correspondants sont peut-être situés derrière des
routeurs/firewalls/autre qui ne comprennent pas le protocole FTP, ce qui
empêche un fonctionnement correct du mode actif: en effet si le client
FTP de votre correspondant utilise ce mode, la commande "PORT" qu'il
enverra à votre serveur inclura son adresse IP *privée*, celle utilisée
sur son LAN, et qui est inaccessible à votre serveur.

Pour que cela fonctionne correctement, il faut que le routeur, la box,
ou de manière plus générale l'équipement qui connecte le client
problématique à Internet comprenne le protocole FTP et sache le
décortiquer afin de remplacer à la volée, dans la commande "PORT",
l'adresse IP privée de la machine cliente sur le LAN, par l'adresse
publique du routeur (avec un éventuel changement de port à la clef si
c'est nécessaire).

C'est la raison la plus probable, à mon avis, de ce mauvais
fonctionnement, mais malheureusement, vous n'y pouvez pas grand-chose, à
part conseiller à vos interlocuteurs de passer en mode passif...

J'ai fait il y a quelques jours une petite capture avec wireshark. Mon
interpétation est loin d'être sûre mais il me semble que tout est correct
sauf une chose : La requête LIST transmise par le client (qui a bien adopté
le mode passif) n'est pas adressée vers le port 30063 que vient de lui
désigner le serveur mais vers le port 21. Cette interprétation est elle
exacte ? Quel est le fautif ? Je suis tenté de dire le client mais je trouve
aussi le serveur un peu prompt à devenir sourd sur le port 21...

http://www.cijoint.fr/cjlink.php?file=cj201105/cijufOilwM.txt

(Le compte de l'utilisateur roky est réel, vous pouvez faire un essai avant
que je change le mot de passe. Merci de ne pas envoyer de gros fichier.)

Par ailleurs, j'ai personnellement réussi une connexion de l'extérieur, en
mode passif, du premier coup, avec gftp, avec échange de fichiers dans les
deux sens.

Cela dit, je suis assez d'accord avec le commentaire de Nicolas George
sur le côté un peu obsolète, désormais, du protocole FTP, qui peut
avantageusement être remplacé par SFTP ou autre chose. Mais bon, il est
évident qu'une telle décision ne peut se faire que si tous vos
correspondants sont à même d'utiliser le nouveau protocole...

J'en vois bien le double intérêt : Sécurité et utilisation d'un seul port.
Je vais leur en parler, merci.

Cordialement,
GC

Le 24/05/2011 17:34, geo cherchetout a écrit :

J'ai fait il y a quelques jours une petite capture avec wireshark. Mon
interpétation est loin d'être sûre mais il me semble que tout est correct
sauf une chose : La requête LIST transmise par le client (qui a bien adopté
le mode passif) n'est pas adressée vers le port 30063 que vient de lui
désigner le serveur mais vers le port 21. Cette interprétation est elle
exacte ? Quel est le fautif ? Je suis tenté de dire le client mais je trouve
aussi le serveur un peu prompt à devenir sourd sur le port 21...

Il est normal que la commande "LIST" soit adressée au port 21. Ce qui
devrait se passer ensuite, en revanche, c'est que les données passent
sur le canal... de données. ;-) En mode passif, celui-ci est établi dans
le même sens que la connexion de commande, mais vers un port > 1023
comme vous le savez, or votre capture ne montre que ce qui se passe sur
le port 21 (en source ou destination). Pour bien analyser ce qui se
passe, il faudrait donc également la trace depuis et vers le port alloué
dynamiquement par le serveur FTP lors du passage en mode passif... Mais
d'après ce que je vois (absence de réponse 150 de la part du serveur),
il y a de grandes chances que ce canal de données n'ait pas pu s'établir.

Je vais faire un test ou deux plus tard dans la soirée.

Autre question: je suis peut-être mal réveillé (quoique, à cette
heure-ci normalement, la sieste est finie ;-) ), mais je vois que votre
IP publique apparaît dans la réponse de votre serveur à la commande
PASV... Vous l'avez configurée quelque part dans Pure-FTPd ? Si c'était
votre routeur/firewall qui s'était chargé du boulot, c'est votre adresse
privée qu'on aurait dû voir à cet endroit...

Cela dit, je suis assez d'accord avec le commentaire de Nicolas George
sur le côté un peu obsolète, désormais, du protocole FTP, qui peut
avantageusement être remplacé par SFTP ou autre chose. Mais bon, il est
évident qu'une telle décision ne peut se faire que si tous vos
correspondants sont à même d'utiliser le nouveau protocole...

J'en vois bien le double intérêt : Sécurité et utilisation d'un seul port.
Je vais leur en parler, merci.

De rien, bonne soirée !

--
Bruno Tréguier

Le 24/05/2011 18:32, *Bruno Tréguier* a écrit fort à propos :

Il est normal que la commande "LIST" soit adressée au port 21. Ce qui
devrait se passer ensuite, en revanche, c'est que les données passent
sur le canal... de données. ;-) En mode passif, celui-ci est établi dans
le même sens que la connexion de commande, mais vers un port > 1023
comme vous le savez, or votre capture ne montre que ce qui se passe sur
le port 21 (en source ou destination). Pour bien analyser ce qui se
passe, il faudrait donc également la trace depuis et vers le port alloué
dynamiquement par le serveur FTP lors du passage en mode passif... Mais
d'après ce que je vois (absence de réponse 150 de la part du serveur),
il y a de grandes chances que ce canal de données n'ait pas pu s'établir.

Mon filtre de capture portant uniquement sur l'ip (publique) du client, je
pense n'avoir rien manqué.

Je vais faire un test ou deux plus tard dans la soirée.

OK.

Autre question: je suis peut-être mal réveillé (quoique, à cette
heure-ci normalement, la sieste est finie ;-) ), mais je vois que votre
IP publique apparaît dans la réponse de votre serveur à la commande
PASV... Vous l'avez configurée quelque part dans Pure-FTPd ? Si c'était
votre routeur/firewall qui s'était chargé du boulot, c'est votre adresse
privée qu'on aurait dû voir à cet endroit...

Je pense que c'est Pure-FTPD qui se charge de faire le nécessaire car il est
lancé avec l'option -P dont l'argument est mon adresse en no-ip.info.

Salut,

geo cherchetout a écrit :

Par ailleurs, j'ai personnellement réussi une connexion de l'extérieur, en
mode passif

Moi pas. Mon client essuie un refus de la connexion sur le port passif
et se replie en mode actif - qui fonctionne.

227 Entering Passive Mode (83,203,8,243,117,216)
ftp: Can't connect to `83.203.8.243': Connection refused
200 PORT command successful
150 Connecting to port 59694

Le paquet RST reçu du port passif a un TTL de 51 alors que les paquets
reçus du port 21 ou de la connexion de données en mode actif ont un TTL
de 50, ce qui peut laisser penser que c'est au niveau du routeur que ça
coince. Ou bien un pare-feu sur le serveur.

Le 24/05/2011 20:02, *Pascal Hambourg* a écrit fort à propos :

Par ailleurs, j'ai personnellement réussi une connexion de l'extérieur, en
mode passif

Moi pas. Mon client essuie un refus de la connexion sur le port passif
et se replie en mode actif - qui fonctionne.

Euh, désolé, lors de mon essai réussi gftp était configuré pour utiliser le
mode passif mais j'ignore totalement s'il n'a pas basculé automatiquement
vers le mode actif.

227 Entering Passive Mode (83,203,8,243,117,216)
ftp: Can't connect to `83.203.8.243': Connection refused
200 PORT command successful
150 Connecting to port 59694

Le paquet RST reçu du port passif a un TTL de 51 alors que les paquets
reçus du port 21 ou de la connexion de données en mode actif ont un TTL
de 50, ce qui peut laisser penser que c'est au niveau du routeur que ça
coince. Ou bien un pare-feu sur le serveur.

Je ne saisis pas encore ce que ça signifie mais je peux déjà dire qu'aucun
pare-feu n'est actif sur mon pc. Seul à ma connaissance mon modem-routeur
(Speedtouch 716v5) filtre ce qui entre. N'ai-je pas eu tort de « forwarder »
les ports 30000-30199 avec trigger-port 21 ?

Le 24/05/2011 à 20:21, geo cherchetout a écrit :

Le 24/05/2011 20:02, *Pascal Hambourg* a écrit fort à propos :

Par ailleurs, j'ai personnellement réussi une connexion de
l'extérieur, en
mode passif

Moi pas. Mon client essuie un refus de la connexion sur le port passif
et se replie en mode actif - qui fonctionne.

Euh, désolé, lors de mon essai réussi gftp était configuré pour utiliser
le mode passif mais j'ignore totalement s'il n'a pas basculé
automatiquement vers le mode actif.

Bonsoir,

J'essuie aussi un refus, ce qui semble montrer que le port alloué pour
la connexion de données n'est pas ouvert.

Même constat que Pascal Hambourg: le TTL est plus élevé de 1 pour le
paquet RST qui sanctionne la tentative d'ouverture du port 30xxx. On
peut donc supposer que ce n'est pas le PC qui est en cause, mais bel et
bien le routeur/firewall devant.

Je reviens sur la configuration de ce dernier d'ailleurs: je ne suis pas
sûr de bien comprendre le fonctionnement, sur votre routeur, de la
fonction "port triggering". Sur le mien, cette fonction sert à réaliser
à la volée des redirections entrantes (du "port forwarding", donc), mais
vers un hôte du LAN qui n'est pas systématiquement le même à chaque
fois: les paquets entrants seront forwardés vers l'hôte à l'origine de
la connexion *sortante* sur un port donné.

Si votre routeur fonctionne un peu de la même manière, il se peut que le
problème se situe là, puisque si j'ai bien compris votre conf, vous
souhaitez que les ports "hauts" (de 30000 à 30199) ne s'ouvrent que sur
réception d'un premier paquet *entrant* sur le port 21 (bon, bien sûr,
après ce 1er paquet TCP il y a des réponses dans le sens sortant depuis
ce port, mais je ne suis pas certain que cela soit pris en compte par le
mécanisme de "port triggering").

Pourriez-vous, juste pour voir, supprimer la dépendance dans la colonne
"port triggering" sur votre configuration de port forwarding ?

Du coup, bien sûr, vos ports hauts resteraient ouverts en permanence,
mais si la plage concernée est limitée (comme c'est le cas ici) et que
ces ports ne correspondent à aucun autre service que le canal de données
éventuellement ouvert à la volée par Pure-FTPd pour une connexion de
données, le risque est tout de même très très limité...

Je ne saisis pas encore ce que ça signifie mais je peux déjà dire
qu'aucun pare-feu n'est actif sur mon pc. Seul à ma connaissance mon
modem-routeur (Speedtouch 716v5) filtre ce qui entre. N'ai-je pas eu
tort de « forwarder » les ports 30000-30199 avec trigger-port 21 ?

Toujours lire un message jusqu'au bout avant de faire une réponse longue
comme un jour sans pain... Silly me. Bon, je vois que vous en arrivez à
la même suspicion sur le "port triggering"... ;-)

Cordialement,

--
Bruno Tréguier

Le 24/05/2011 22:43, *Bruno Tréguier* a écrit fort à propos :

Je reviens sur la configuration de ce dernier d'ailleurs: je ne suis pas
sûr de bien comprendre le fonctionnement, sur votre routeur, de la
fonction "port triggering". Sur le mien, cette fonction sert à réaliser
à la volée des redirections entrantes (du "port forwarding", donc), mais
vers un hôte du LAN qui n'est pas systématiquement le même à chaque
fois: les paquets entrants seront forwardés vers l'hôte à l'origine de
la connexion *sortante* sur un port donné.

Si votre routeur fonctionne un peu de la même manière, il se peut que le
problème se situe là, puisque si j'ai bien compris votre conf, vous
souhaitez que les ports "hauts" (de 30000 à 30199) ne s'ouvrent que sur
réception d'un premier paquet *entrant* sur le port 21 (bon, bien sûr,
après ce 1er paquet TCP il y a des réponses dans le sens sortant depuis
ce port, mais je ne suis pas certain que cela soit pris en compte par le
mécanisme de "port triggering").

En effet, je prenais peut-être mes rêves pour des réalités...

Pourriez-vous, juste pour voir, supprimer la dépendance dans la colonne
"port triggering" sur votre configuration de port forwarding ?

Voilà, je viens de le faire.

geo cherchetout a écrit :

Le 24/05/2011 22:43, *Bruno Tréguier* a écrit fort à propos :

Pourriez-vous, juste pour voir, supprimer la dépendance dans la colonne
"port triggering" sur votre configuration de port forwarding ?

Voilà, je viens de le faire.

Maintenant je reçois un RST lors de tentatives de connexion sur les
ports de la plage 30000-30199, avec un TTL de 50 comme les paquets de
réponse du port 21, donc c'est a priori le serveur qui répond que le
port est fermé. Avant je ne recevais pas de réponse du tout, sauf le RST
pour le port passif. J'observe des différences entre le RST pour un port
quelconque dans l'intervalle et celui pour le port passif indiqué dans
la réponse du serveur à la commande PASV.
- port passif : TTL à 50 et ID non nul
- autres ports : TTL à 51 et ID systématiquement nul

Cela renforce l'hypothèse selon laquelle le RST pour le port passif
n'est pas émis par le serveur mais par le routeur. Cela laisse penser
également que le routeur interprète le protocole FTP puisqu'il est
capable de faire un traitement différent sur le port passif.

Une hypothèse serait que le problème vienne de ce que le serveur indique
l'adresse publique (du routeur) et non l'adresse privée dans sa réponse
à la commande PASV. C'est ce qu'il faut faire lorsque le routeur ne
comprend pas le protocole FTP en mode passif, mais j'imagine que cela
peut l'induire en erreur dans le cas contraire. Dans ce cas la tentative
de connexion au port passif pourrait aboutir sur le routeur lui-même,
dont le port correspondant et évidemment fermé, d'où le RST.

Peux-tu tester en laissant le serveur indiquer son adresse privée, comme
ça doit être par défaut ?