Mise en route d'un serveur FTP

Le Mon, 2 Feb 2009 08:26:24 -0800 (PST), sandega@gmail.com a écrit
dans le message
<47338b04-f07d-4065-b95a-c73b288adb00@17g2000vbf.googlegroups.com> :

Est-ce la bonne manière de procéder ?

A priori oui pour le FTP.

A mon avis le problème est plus au niveau du réseau.

Si la seconde machine passe par un routeur NAT pour voir
l'adresse IP publique de la première ---> pas bon.

Si le serveur FTP est derrière un routeur NAT ---> ça va poser
pas mal de problèmes, le FTP n'étant pas trivial à translater.

--
Raphael Bouaziz.

On Monday 02 February 2009 17:26, sandega@gmail.com wrote:

j'essaie de mettre en place un serveur FTP sur mon poste (XP SP3),
pour accéder à mes documents depuis l'extérieur (j'ai regardé d'autres
solutions, mais pour l'instant je préfère tester le FTP).

C'est une très mauvaise idée. Le FTP est un protocole obsolète, qui n'assure
aucune sécurité, et qui est très capricieux.
Le principale inconvénient, c'est que FTP utilise deux connexions. La
première connexion, dite connexion de contrôle, sert à l'authentification
(qui n'est nullement protégée) et à passer les commandes FTP. Cette
connexion est établie vers le port 21 du serveur.
La seconde connexion est la connexion de données, qui est établie de manière
dynamique, pour l'échange de données (transfert d'un fichier, listing d'un
répertoire, etc...). Cette connexion est soit établie par le client vers un
port aléatoire du serveur (mode actif), soit établie par le serveur vers le
client (mode passif). Les ports et adresses n'étant pas définis, cela pose
souvent des soucis dès lors que la connexion traverse un mécanisme de NAT.

Bref, le FTP n'est certainement pas un protocole que j'utiliserais :-)
Se diriger plutôt vers l'HTTP (si pas besoin d'accès aux données en
écriture), sinon SFTP (qui, malgré le nom, n'a rien à voir avec FTP).
Sinon, si pas besoin d'authentification (ie. les données sont de type
publique), un serveur Gopher pourrait aussi s'avérer sympa ;-)

Cordialement,
Mateusz Viste

On 2 fév, 20:37, Mateusz Viste
<mateusz.visteATmailDO...@invalid.invalid> wrote:

Bref, le FTP n'est certainement pas un protocole que j'utiliserais :-)
Se diriger plutôt vers l'HTTP (si pas besoin d'accès aux données en
écriture), sinon SFTP (qui, malgré le nom, n'a rien à voir avec FTP ).
Sinon, si pas besoin d'authentification (ie. les données sont de type
publique), un serveur Gopher pourrait aussi s'avérer sympa ;-)

Merci de ta réponse !
Ok, j'ai compris, le ftp ce n'est pas le bon choix, il s'agit en effet
de données privées.

J'ai cherché des infos sur SFTP, mais je ne vois pas comment faire
l'installation d'un serveur sous windows xp (pour le client, FileZilla
semble fonctionner).
Je vois que c'est un pur produit de la open-culture... tout à son
honneur.
Pour l'instant je cherche quelque chose d'accessible sous Win et sous
MacOS.

Pourrais-tu me donner quelques indications pour démarrer la mise en
place d'un serveur SFTP.
Pour info : tous les postes sont bien derrière des routeurs.

Merci d'avance !

sandega

sandega@gmail.com a écrit :

Bonjour,

J'ai récupéré mon adresse IP (par ex: sur le site http://www.mon-ip.com/)
: 80.13.97.XXX

Sur ma deuxième machine, j'ai ouvert IE et tapé "ftp://80.13.97.XXX"
dans la barre de l'adresse.

Je m'attendais à voir une fenêtre me demandant mon profil client, mais
un message d'erreur s'affiche.

Salut,

Ca ne marchera pas depuis votre réseau local avec l'adresse ip externe (
hors routeur intelligent ).
Pour vos tests, commencez par l'adresse interne 192.168.x.y par ex.
Il faudra rediriger un/des ports pour accéder à la machine depuis
l'extérieur (vrai, en général qq soit le protocole utilisé )

Je vous recommande un vpn tel que openvpn. Une fois le vpn en place,
vous pourrez y faire passer ce que vous voulez, partage de fichier, ftp,
rdp...
C'est plus complexe initialement mais une fois en place, vous travaillez
comme depuis votre réseau local.

http://openvpn.net/
Tuto
http://forum.hardware.fr/hfr/reseauxpersosoho/Tutoriels/windows-openvpn-tutoriels-sujet_2_1.htm



--
DR

On Monday 02 February 2009 22:18, sandega@gmail.com wrote:

Ok, j'ai compris, le ftp ce n'est pas le bon choix, il s'agit en effet
de données privées.

La seconde question à se poser, c'est si ces données doivent être également
accessibles en écriture? Si oui -> SFTP, sinon -> HTTP (authentifié, et
éventuellement chiffré via SSL). L'intérêt de HTTP(S), c'est qu'un client
HTTP/HTTPS est présent sur tout les postes, donc possibilité d'accéder à
ses données depuis vraiment n'importe quel poste.

J'ai cherché des infos sur SFTP, mais je ne vois pas comment faire
l'installation d'un serveur sous windows xp (pour le client, FileZilla
semble fonctionner).

J'avoue ne jamais avoir installé de serveur SFTP sous Windoze... Quelle idée
saugrenue, aussi, d'utiliser un système pareil, alors que nous avons à
disposition de nombreux systèmes bien plus performants, et beaucoup moins
onéreux? ;-)

Par pure curiosité intellectuelle, j'ai fais une rapide recherche, et suis
tombé sur:
http://en.wikipedia.org/wiki/List_of_SFTP_servers

Manifestement, il existe des serveurs SFTP même sous Windoze (dont un
portage Cygwin d'OpenSSH).

Pour l'instant je cherche quelque chose d'accessible sous Win et sous
MacOS.

HTTP et SFTP le sont.

Pourrais-tu me donner quelques indications pour démarrer la mise en
place d'un serveur SFTP.

Commencer par visiter le lien que j'ai soumis plus haut, et choisir le
serveur qui sera utilisé (il te faudra probablement les installer tous,
pour choisir le produit qui te convient le mieux).

Pour info : tous les postes sont bien derrière des routeurs.

Cela n'a pas d'importance. C'est gênant uniquement pour FTP, qui utilise une
connexion fille dynamique. Il te faudra simplement rediriger un port depuis
le retour, vers la machine serveur (port TCP/80 pour HTTP, TCP/22 pour
SSH/SCP/SFTP).

Cordialement,
Mateusz Viste

Salut,

Mateusz Viste a écrit :

C'est une très mauvaise idée. Le FTP est un protocole obsolète, qui n'assure
aucune sécurité, et qui est très capricieux.

Ben voyons...

Le principale inconvénient, c'est que FTP utilise deux connexions.

En cela FTP n'est pas différent d'autres protocoles tels que SIP pour la
VoIP ou RTSP pour le streaming audio/vidéo en temps réel. Est-ce à dire
que ce sont aussi des protocoles obsolètes et capricieux ?

La
première connexion, dite connexion de contrôle, sert à l'authentification
(qui n'est nullement protégée) et à passer les commandes FTP.

La connection de commande peut être chiffrée par TLS/SSL, de même que
les connexions de données.

La seconde connexion est la connexion de données, qui est établie de manière
dynamique, pour l'échange de données (transfert d'un fichier, listing d'un
répertoire, etc...). Cette connexion est soit établie par le client vers un
port aléatoire du serveur (mode actif), soit établie par le serveur vers le
client (mode passif).

C'est l'inverse.
Mode actif = connexion de données établie par le serveur vers le client
Mode passif = connexion de données établie par le client vers le serveur

Les ports et adresses n'étant pas définis, cela pose
souvent des soucis dès lors que la connexion traverse un mécanisme de NAT.

Les ports dynamiques servant à recevoir les connexions de données
peuvent être limités à une plage donnée, ce qui facilite le travail de
NAT et de filtrage. Le pare-feu/NAT peut aussi analyser le contenu de la
connexion de commande pour déterminer les ports à ouvrir/rediriger, mais
seulement si elle n'est pas chiffrée.

Bonjour,

On Wednesday 04 February 2009 12:04, Pascal Hambourg wrote:

En cela FTP n'est pas différent d'autres protocoles tels que SIP pour la
VoIP ou RTSP pour le streaming audio/vidéo en temps réel. Est-ce à dire
que ce sont aussi des protocoles obsolètes et capricieux ?

Non, les contraintes ne sont pas du tout les mêmes. FTP sert à échanger des
données, sans obligation de latences faible. Ce n'est pas le cas pour les
flux temps réel, où il est nécessaire de transmettre de nombreux petits
paquets rapidement (d'où l'utilisation d'UDP pour ce type
d'applications)...

La connection de commande peut être chiffrée par TLS/SSL, de même que
les connexions de données.

On ne parlera alors plus de FTP, mais plutôt de FTP/S...
À noter, que Le chiffrement du canal de contrôle rend la communication FTP
encore moins gérable, dans la mesure ou les éventuelles passerelles NAT
et/ou firewalls ne savent plus interpréter/réécrire les données transitant
dans la connexion de contrôle.

C'est l'inverse.
Mode actif = connexion de données établie par le serveur vers le client
Mode passif = connexion de données établie par le client vers le serveur

On est d'accord. J'ai tapé mon post un peu vite, sans relire :-)

Les ports dynamiques servant à recevoir les connexions de données
peuvent être limités à une plage donnée, ce qui facilite le travail de
NAT et de filtrage.

Côté serveur, cela veut dire qu'il est nécessaire d'ouvrir en permanence une
plage de ports, redirigée vers notre serveur interne. Bof...

Côté client, c'est plus que contraignant. En mode actif, le client devra
s'astreindre à configurer son client FTP à annoncer un port depuis cette
plage de ports, et rediriger les ports nécessaire depuis son
router/passerelle vers le poste utilisateur. De plus, le client doit
être "conscient" de son adresse translatée, afin de la déclarer
correctement.

Évidemment, le problème ne se pose pas si ledit routeur sait réécrire le
canal de contrôle FTP à la volée (substituer l'IP client par sa propre IP
publique), et ouvrir/rediriger dynamiquement les ports utilisés... De
nouveau, cela ajoute une complexité inutile au mécanisme.

Le pare-feu/NAT peut aussi analyser le contenu de la
connexion de commande pour déterminer les ports à ouvrir/rediriger, mais
seulement si elle n'est pas chiffrée.

Ah, c'est justement ce que je viens d'écrire plus haut :-)

Bref, je ne vois strictement aucun intêret à utiliser le FTP aujourd'hui,
alors que nous disposons de protocoles bien plus évolués, ne nécessitant
aucun bidouillage sur le NAT ou le filtrage.

Cordialement,
Mateusz Viste

Mateusz Viste <mateusz.visteATmailDOTru@invalid.invalid> écrivait :

Bref, je ne vois strictement aucun intêret à utiliser le FTP aujourd'hui,
alors que nous disposons de protocoles bien plus évolués, ne nécessitant
aucun bidouillage sur le NAT ou le filtrage.

Euh tu remplcae ftp par quoi ? Htpp ? Avec upload encodé en base 64 ?

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé

On Thursday 05 February 2009 11:34, Erwan David wrote:

Euh tu remplcae ftp par quoi ? Htpp ? Avec upload encodé en base 64 ?

C'est une idée. L'avantage, c'est qu'un client HTTP/HTTPS est disponible sur
n'importe quel poste client. L'extension WebDav pourrait alors être
envisageable.

Toutefois, comme mentionné dans mon post initial, j'aurais plutôt tendance à
me tourner vers SCP / SFTP.

Cordialement,
Mateusz Viste

Mateusz Viste a écrit :

On Wednesday 04 February 2009 12:04, Pascal Hambourg wrote:

En cela FTP n'est pas différent d'autres protocoles tels que SIP pour la
VoIP ou RTSP pour le streaming audio/vidéo en temps réel. Est-ce à dire
que ce sont aussi des protocoles obsolètes et capricieux ?

Non, les contraintes ne sont pas du tout les mêmes. FTP sert à échanger des
données, sans obligation de latences faible. Ce n'est pas le cas pour les
flux temps réel, où il est nécessaire de transmettre de nombreux petits
paquets rapidement (d'où l'utilisation d'UDP pour ce type
d'applications)...

Aucun rapport avec le sujet, à savoir que tous ces protocoles utilisent
plusieurs "connexions" (ou flux si on estime que le terme "connexion"
est impropre pour une communication UDP) avec des ports distincts et
même parfois des hôtes distincts.

À noter, que Le chiffrement du canal de contrôle rend la communication FTP
encore moins gérable, dans la mesure ou les éventuelles passerelles NAT
et/ou firewalls ne savent plus interpréter/réécrire les données transitant
dans la connexion de contrôle.

J'en parlais plus bas. Le même problème se pose quand la connexion de
commande se fait sur un port non standard, car les firewalls/NAT ne
surveillent que le port 21. Certains permettent de spécifier d'autres
ports, mais il faut configurer explicitement pour chaque port
susceptible de transporter du FTP.

Les ports dynamiques servant à recevoir les connexions de données
peuvent être limités à une plage donnée, ce qui facilite le travail de
NAT et de filtrage.

Côté serveur, cela veut dire qu'il est nécessaire d'ouvrir en permanence une
plage de ports, redirigée vers notre serveur interne. Bof...

Ce n'est pas une contrainte monstrueuse. Après tout, c'est un serveur.

Côté client, c'est plus que contraignant. En mode actif, le client devra
s'astreindre à configurer son client FTP à annoncer un port depuis cette
plage de ports, et rediriger les ports nécessaire depuis son
router/passerelle vers le poste utilisateur. De plus, le client doit
être "conscient" de son adresse translatée, afin de la déclarer
correctement.

Je suis assez d'accord. On ne peut pas raisonnablement demander au
client lambda de faire tout ça. Donc si on veut faire du FTP chiffré, il
vaut mieux utiliser le mode passif (ça tombe bien, tous les clients FTP
modernes l'utilisent par défaut), et idéalement le mode passif étendu
(EPSV) qui évite au serveur de devoir connaître son adresse publique
s'il est derrière un NAT. Ainsi le firewall/NAT du client devra
simplement autoriser les connexion sortantes, sans besoin d'analyser le
contenu ou ouvrir/rediriger des ports en entrée.

Évidemment, le problème ne se pose pas si ledit routeur sait réécrire le
canal de contrôle FTP à la volée (substituer l'IP client par sa propre IP
publique), et ouvrir/rediriger dynamiquement les ports utilisés... De
nouveau, cela ajoute une complexité inutile au mécanisme.

Bah, la plupart des routeurs NAT savent le faire. Le problème c'est que
c'est inapplicable lorsque la connexion de commande est chiffrée ou sur
un port non standard.