J'ai installé un serveur FTP (Filezilla) sur un Windows 2000 (Le chef
veut pas de Lunux, snif). Via une IP fixe, on peut se connecter de
l'extérieur à ce serveur, en passant pas un petit modem Ethernet qui ne
ne laisse passer que le port 21 vers ce serveur (via un switch).
J'ai viré le compte Anonyme sur le serveur et les users ont tous un mot
de passe pour se connecter. Il faut aussi savoir que les fichiers
disponibles ne sont pas trés "sensibles".
Quel est le niveau de sécurité d'un tel serveur FTP ?
Est-ce /trés facile/facile/c'est pas évident/faut être vraiment bon/
pour arriver à pirater un serveur FTP de l'extérieur ?
Mais je commence à me demander si il ne vaudrait pas mieux installer un
serveur SSH ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
plonky
Bonjour,
Le protocol ftp se distingue par deux canaux de communication. Un canal de commande, generalement en ecoute sur le port 21, et un canal de donnees, gere dynamiquement suivant le mode de transfert (active ou passive), par lequel s'effecture le transfert de fichiers.
Securiser un serveur ftp ne se fait pas de maniere trivial. Tout d'abord, il faut s'attacher a securiser l'authentification. Ceci ce fait generalement par du SSL ou TLS de sorte que le login et le mot de passe ne transite pas en clair sur le reseau. Ensuite il est conseille de crypte le canal de commande par SSL, de sorte que personne ne puisse intercepte les commandes, et pouvoir connaitre l'arborescence du systeme de fichier serveur.
Pour les plus paranoiaques, il est aussi possible de crypte le canal de donnee aussi (Toujours pas SSL)
Dans ta configuration, il est necessaire de gerer le canal de donnee en mode passif. Dans le mode passif, le client ftp specifie un port sur lequel il ecoute pres a recevoir les donnees, et le serveur est charge d'etablir la connection sur ce port. Comme ton routeur ne laisse passer que les packets a destination sur le port 21, il n'est pas possible de faire tourner ton serveur en mode actif (le serveur specifie un port (!!) en local, et le client s'y connecte.)
Pour windows, je te conseillerais raidenftp, serv-u, gen6 ftp server, qui dans l'ensemble supportent le ssl et le tls. Et comme client pour ne pas avoir de probleme, flashfxp est tres complet au niveau des modes de connection et transfert (support ssl, tls ...)
Cordialement
-- Plonky
Bonjour,
Le protocol ftp se distingue par deux canaux de communication.
Un canal de commande, generalement en ecoute sur le port 21, et un
canal de donnees, gere dynamiquement suivant le mode de transfert
(active ou passive), par lequel s'effecture le transfert de fichiers.
Securiser un serveur ftp ne se fait pas de maniere trivial.
Tout d'abord, il faut s'attacher a securiser l'authentification. Ceci
ce fait generalement par du SSL ou TLS de sorte que le login et le mot
de passe ne transite pas en clair sur le reseau. Ensuite il est
conseille de crypte le canal de commande par SSL, de sorte que personne
ne puisse intercepte les commandes, et pouvoir connaitre l'arborescence
du systeme de fichier serveur.
Pour les plus paranoiaques, il est aussi possible de crypte le canal de
donnee aussi (Toujours pas SSL)
Dans ta configuration, il est necessaire de gerer le canal de donnee en
mode passif. Dans le mode passif, le client ftp specifie un port sur
lequel il ecoute pres a recevoir les donnees, et le serveur est charge
d'etablir la connection sur ce port. Comme ton routeur ne laisse passer
que les packets a destination sur le port 21, il n'est pas possible de
faire tourner ton serveur en mode actif (le serveur specifie un port
(!!) en local, et le client s'y connecte.)
Pour windows, je te conseillerais raidenftp, serv-u, gen6 ftp server,
qui dans l'ensemble supportent le ssl et le tls. Et comme client pour
ne pas avoir de probleme, flashfxp est tres complet au niveau des modes
de connection et transfert (support ssl, tls ...)
Le protocol ftp se distingue par deux canaux de communication. Un canal de commande, generalement en ecoute sur le port 21, et un canal de donnees, gere dynamiquement suivant le mode de transfert (active ou passive), par lequel s'effecture le transfert de fichiers.
Securiser un serveur ftp ne se fait pas de maniere trivial. Tout d'abord, il faut s'attacher a securiser l'authentification. Ceci ce fait generalement par du SSL ou TLS de sorte que le login et le mot de passe ne transite pas en clair sur le reseau. Ensuite il est conseille de crypte le canal de commande par SSL, de sorte que personne ne puisse intercepte les commandes, et pouvoir connaitre l'arborescence du systeme de fichier serveur.
Pour les plus paranoiaques, il est aussi possible de crypte le canal de donnee aussi (Toujours pas SSL)
Dans ta configuration, il est necessaire de gerer le canal de donnee en mode passif. Dans le mode passif, le client ftp specifie un port sur lequel il ecoute pres a recevoir les donnees, et le serveur est charge d'etablir la connection sur ce port. Comme ton routeur ne laisse passer que les packets a destination sur le port 21, il n'est pas possible de faire tourner ton serveur en mode actif (le serveur specifie un port (!!) en local, et le client s'y connecte.)
Pour windows, je te conseillerais raidenftp, serv-u, gen6 ftp server, qui dans l'ensemble supportent le ssl et le tls. Et comme client pour ne pas avoir de probleme, flashfxp est tres complet au niveau des modes de connection et transfert (support ssl, tls ...)
Cordialement
-- Plonky
Pascal
Salut,
[Serveur FTP derrière un modem filtrant (???) tout en entrée sauf le port TCP 21]
Le protocol ftp se distingue par deux canaux de communication. Un canal de commande, generalement en ecoute sur le port 21, et un canal de donnees, gere dynamiquement suivant le mode de transfert (active ou passive), par lequel s'effecture le transfert de fichiers.
Securiser un serveur ftp ne se fait pas de maniere trivial. Tout d'abord, il faut s'attacher a securiser l'authentification. Ceci ce fait generalement par du SSL ou TLS de sorte que le login et le mot de passe ne transite pas en clair sur le reseau. Ensuite il est conseille de crypte le canal de commande par SSL, de sorte que personne ne puisse intercepte les commandes, et pouvoir connaitre l'arborescence du systeme de fichier serveur.
Comme le listage de répertoire passe par un canal de données, chiffrer le canal de commande ne suffit pas à cacher l'arborescence.
Pour les plus paranoiaques, il est aussi possible de crypte le canal de donnee aussi (Toujours pas SSL)
Dans ta configuration, il est necessaire de gerer le canal de donnee en mode passif. Dans le mode passif, le client ftp specifie un port sur lequel il ecoute pres a recevoir les donnees, et le serveur est charge d'etablir la connection sur ce port.
Ce que tu décris est au contraire le mode actif. Le mode passif, c'est l'inverse : le serveur attend la connexion de données.
Comme ton routeur ne laisse passer que les packets a destination sur le port 21, il n'est pas possible de faire tourner ton serveur en mode actif (le serveur specifie un port (!!) en local, et le client s'y connecte.)
Dans la phrase qui précède, remplacer "actif" par "passif" : "il n'est pas possible de faire tourner ton serveur en mode actif".
Et les ennuis arrivent quand le client est lui aussi derrière un firewall ou un dispositif NAT, ce qui est un cas fort courant : il ne peut faire que du FTP passif alors que de son côté le serveur ne peut faire que du FTP actif. Bref, impossible de faire des transferts. Pour y remédier, les routeurs/firewalls de qualité interceptent le contenu du canal de commande pour accepter les connexions de données entrantes, mais si le canal de commande est chiffré ça ne marche plus. A moins que la position de "man in the middle" du routeur/firewall lui permette de déchiffrer le contenu du canal de commande ? Mes notions de SSL/TLS sont plus que nébuleuses, mais j'imagine que ces protocoles sont prévus pour s'en prémunir.
Salut,
[Serveur FTP derrière un modem filtrant (???) tout en entrée sauf le
port TCP 21]
Le protocol ftp se distingue par deux canaux de communication.
Un canal de commande, generalement en ecoute sur le port 21, et un
canal de donnees, gere dynamiquement suivant le mode de transfert
(active ou passive), par lequel s'effecture le transfert de fichiers.
Securiser un serveur ftp ne se fait pas de maniere trivial.
Tout d'abord, il faut s'attacher a securiser l'authentification. Ceci
ce fait generalement par du SSL ou TLS de sorte que le login et le mot
de passe ne transite pas en clair sur le reseau. Ensuite il est
conseille de crypte le canal de commande par SSL, de sorte que personne
ne puisse intercepte les commandes, et pouvoir connaitre l'arborescence
du systeme de fichier serveur.
Comme le listage de répertoire passe par un canal de données, chiffrer
le canal de commande ne suffit pas à cacher l'arborescence.
Pour les plus paranoiaques, il est aussi possible de crypte le canal de
donnee aussi (Toujours pas SSL)
Dans ta configuration, il est necessaire de gerer le canal de donnee en
mode passif. Dans le mode passif, le client ftp specifie un port sur
lequel il ecoute pres a recevoir les donnees, et le serveur est charge
d'etablir la connection sur ce port.
Ce que tu décris est au contraire le mode actif. Le mode passif, c'est
l'inverse : le serveur attend la connexion de données.
Comme ton routeur ne laisse passer
que les packets a destination sur le port 21, il n'est pas possible de
faire tourner ton serveur en mode actif (le serveur specifie un port
(!!) en local, et le client s'y connecte.)
Dans la phrase qui précède, remplacer "actif" par "passif" : "il n'est
pas possible de faire tourner ton serveur en mode actif".
Et les ennuis arrivent quand le client est lui aussi derrière un
firewall ou un dispositif NAT, ce qui est un cas fort courant : il ne
peut faire que du FTP passif alors que de son côté le serveur ne peut
faire que du FTP actif. Bref, impossible de faire des transferts. Pour y
remédier, les routeurs/firewalls de qualité interceptent le contenu du
canal de commande pour accepter les connexions de données entrantes,
mais si le canal de commande est chiffré ça ne marche plus. A moins que
la position de "man in the middle" du routeur/firewall lui permette de
déchiffrer le contenu du canal de commande ? Mes notions de SSL/TLS sont
plus que nébuleuses, mais j'imagine que ces protocoles sont prévus pour
s'en prémunir.
[Serveur FTP derrière un modem filtrant (???) tout en entrée sauf le port TCP 21]
Le protocol ftp se distingue par deux canaux de communication. Un canal de commande, generalement en ecoute sur le port 21, et un canal de donnees, gere dynamiquement suivant le mode de transfert (active ou passive), par lequel s'effecture le transfert de fichiers.
Securiser un serveur ftp ne se fait pas de maniere trivial. Tout d'abord, il faut s'attacher a securiser l'authentification. Ceci ce fait generalement par du SSL ou TLS de sorte que le login et le mot de passe ne transite pas en clair sur le reseau. Ensuite il est conseille de crypte le canal de commande par SSL, de sorte que personne ne puisse intercepte les commandes, et pouvoir connaitre l'arborescence du systeme de fichier serveur.
Comme le listage de répertoire passe par un canal de données, chiffrer le canal de commande ne suffit pas à cacher l'arborescence.
Pour les plus paranoiaques, il est aussi possible de crypte le canal de donnee aussi (Toujours pas SSL)
Dans ta configuration, il est necessaire de gerer le canal de donnee en mode passif. Dans le mode passif, le client ftp specifie un port sur lequel il ecoute pres a recevoir les donnees, et le serveur est charge d'etablir la connection sur ce port.
Ce que tu décris est au contraire le mode actif. Le mode passif, c'est l'inverse : le serveur attend la connexion de données.
Comme ton routeur ne laisse passer que les packets a destination sur le port 21, il n'est pas possible de faire tourner ton serveur en mode actif (le serveur specifie un port (!!) en local, et le client s'y connecte.)
Dans la phrase qui précède, remplacer "actif" par "passif" : "il n'est pas possible de faire tourner ton serveur en mode actif".
Et les ennuis arrivent quand le client est lui aussi derrière un firewall ou un dispositif NAT, ce qui est un cas fort courant : il ne peut faire que du FTP passif alors que de son côté le serveur ne peut faire que du FTP actif. Bref, impossible de faire des transferts. Pour y remédier, les routeurs/firewalls de qualité interceptent le contenu du canal de commande pour accepter les connexions de données entrantes, mais si le canal de commande est chiffré ça ne marche plus. A moins que la position de "man in the middle" du routeur/firewall lui permette de déchiffrer le contenu du canal de commande ? Mes notions de SSL/TLS sont plus que nébuleuses, mais j'imagine que ces protocoles sont prévus pour s'en prémunir.
plonky
Comme le listage de répertoire passe par un canal de données, chiffrer le canal de commande ne suffit pas à cacher l'arborescence.
effectivement, petit oublis de ma part
Ce que tu décris est au contraire le mode actif. Le mode passif, c'est l'inverse : le serveur attend la connexion de données.
effectivement, apres relecture de la rfc, j'ai faux. Ceci etant dit, le principe est la.
Mais toutefois je pense que ma reponse s'ecartait du sujet initial.
Outre le probleme de serveur et client chacun derriere un par-feu, ta configuration n'est pas si bonne que cela.
Il ne s'agit pas d'etre bon ou mauvais. Il s'agit principalement de savoir si le logiciel serveur est vulnerable. Si la faille intervient avant ou pendant l'authentification alors ca sera tres facil. Si la faille est apres l'authentification, il faudra prealablement posseder un compte valide sur ton serveur (d'ou l'utilite d'enlever tous les comptes par defaut *anonyme*guest*invite*test*admin* ou de les restreindre au localhost) ce qui justifie l'authenficiation par TLS. De plus, la majorite des serveurs ftp (raiden, ioftpd... ) peuvent filtrer les utilisateurs par ip ou plage d'adresse(et ident) (dans le cas de connection non fixe), cela augmente juste un peu la difficulte
Cordialement
-- Plonky
Comme le listage de répertoire passe par un canal de données, chiffrer
le canal de commande ne suffit pas à cacher l'arborescence.
effectivement, petit oublis de ma part
Ce que tu décris est au contraire le mode actif. Le mode passif, c'est
l'inverse : le serveur attend la connexion de données.
effectivement, apres relecture de la rfc, j'ai faux. Ceci etant dit, le
principe est la.
Mais toutefois je pense que ma reponse s'ecartait du sujet initial.
Outre le probleme de serveur et client chacun derriere un par-feu, ta
configuration n'est pas si bonne que cela.
Il ne s'agit pas d'etre bon ou mauvais. Il s'agit principalement de
savoir si le logiciel serveur est vulnerable.
Si la faille intervient avant ou pendant l'authentification alors ca
sera tres facil. Si la faille est apres l'authentification, il faudra
prealablement posseder un compte valide sur ton serveur (d'ou l'utilite
d'enlever tous les comptes par defaut *anonyme*guest*invite*test*admin*
ou de les restreindre au localhost) ce qui justifie l'authenficiation
par TLS.
De plus, la majorite des serveurs ftp (raiden, ioftpd... ) peuvent
filtrer les utilisateurs par ip ou plage d'adresse(et ident) (dans le
cas de connection non fixe), cela augmente juste un peu la difficulte
Comme le listage de répertoire passe par un canal de données, chiffrer le canal de commande ne suffit pas à cacher l'arborescence.
effectivement, petit oublis de ma part
Ce que tu décris est au contraire le mode actif. Le mode passif, c'est l'inverse : le serveur attend la connexion de données.
effectivement, apres relecture de la rfc, j'ai faux. Ceci etant dit, le principe est la.
Mais toutefois je pense que ma reponse s'ecartait du sujet initial.
Outre le probleme de serveur et client chacun derriere un par-feu, ta configuration n'est pas si bonne que cela.
Il ne s'agit pas d'etre bon ou mauvais. Il s'agit principalement de savoir si le logiciel serveur est vulnerable. Si la faille intervient avant ou pendant l'authentification alors ca sera tres facil. Si la faille est apres l'authentification, il faudra prealablement posseder un compte valide sur ton serveur (d'ou l'utilite d'enlever tous les comptes par defaut *anonyme*guest*invite*test*admin* ou de les restreindre au localhost) ce qui justifie l'authenficiation par TLS. De plus, la majorite des serveurs ftp (raiden, ioftpd... ) peuvent filtrer les utilisateurs par ip ou plage d'adresse(et ident) (dans le cas de connection non fixe), cela augmente juste un peu la difficulte
Cordialement
-- Plonky
Fabien LE LEZ
On 07 Aug 2005 11:28:41 GMT, Corsica :
J'ai installé un serveur FTP (Filezilla) sur un Windows 2000 (Le chef veut pas de Lunux, snif). Via une IP fixe, on peut se connecter de l'extérieur à ce serveur,
Et à quoi ce serveur va-t-il servir ? Suivant l'utilité, il y a d'autres moyens de transférer des fichiers, qui ne posent pas le problème de la double connexion FTP : - http (ou plutôt https ici) - rsync (ou unison) over ssh ...et sans doute pas mal d'autres.
FTP a un gros point fort : il est très répandu, donc tu n'as pas à faire de formation ou envoyer des logiciels. Dans ton cas, j'imagine que le nombre de personnes à accéder à ta machine est très réduit (moins d'une dizaine -- au-delà c'est le bordel), donc une solution moins classique n'est pas gênante.
On 07 Aug 2005 11:28:41 GMT, Corsica <spam.pubb2000@laposte.net>:
J'ai installé un serveur FTP (Filezilla) sur un Windows 2000 (Le chef
veut pas de Lunux, snif). Via une IP fixe, on peut se connecter de
l'extérieur à ce serveur,
Et à quoi ce serveur va-t-il servir ?
Suivant l'utilité, il y a d'autres moyens de transférer des fichiers,
qui ne posent pas le problème de la double connexion FTP :
- http (ou plutôt https ici)
- rsync (ou unison) over ssh
...et sans doute pas mal d'autres.
FTP a un gros point fort : il est très répandu, donc tu n'as pas à
faire de formation ou envoyer des logiciels.
Dans ton cas, j'imagine que le nombre de personnes à accéder à ta
machine est très réduit (moins d'une dizaine -- au-delà c'est le
bordel), donc une solution moins classique n'est pas gênante.
J'ai installé un serveur FTP (Filezilla) sur un Windows 2000 (Le chef veut pas de Lunux, snif). Via une IP fixe, on peut se connecter de l'extérieur à ce serveur,
Et à quoi ce serveur va-t-il servir ? Suivant l'utilité, il y a d'autres moyens de transférer des fichiers, qui ne posent pas le problème de la double connexion FTP : - http (ou plutôt https ici) - rsync (ou unison) over ssh ...et sans doute pas mal d'autres.
FTP a un gros point fort : il est très répandu, donc tu n'as pas à faire de formation ou envoyer des logiciels. Dans ton cas, j'imagine que le nombre de personnes à accéder à ta machine est très réduit (moins d'une dizaine -- au-delà c'est le bordel), donc une solution moins classique n'est pas gênante.
Corsica
On 07 Aug 2005 11:28:41 GMT, Corsica :
Et à quoi ce serveur va-t-il servir ? Suivant l'utilité, il y a d'autres moyens de transférer des fichiers, qui ne posent pas le problème de la double connexion FTP : - http (ou plutôt https ici) - rsync (ou unison) over ssh ...et sans doute pas mal d'autres.
FTP a un gros point fort : il est très répandu, donc tu n'as pas à faire de formation ou envoyer des logiciels. Dans ton cas, j'imagine que le nombre de personnes à accéder à ta machine est très réduit (moins d'une dizaine -- au-delà c'est le bordel), donc une solution moins classique n'est pas gênante.
Bonjour
Merci pour vos réponses. Ce serveur FTP sert principalement à mettre à ma disposition des fichiers d'install quand je vais chez les clients. Mais, il me sert aussi (allez, pour 30%) à mettre à disposition des fichiers pour des clients & fournisseurs (avec répertoire particulier, mais je leur communique un login & mdp bien particulier). Donc, il me fallait une solution avec une sécurité correcte (mais les fichiers ne sont pas trés important), mais qui soit facilement accessible pour un grand nombres de clients/fournisseurs.
Bien le Bonjour de Corse
On 07 Aug 2005 11:28:41 GMT, Corsica <spam.pubb2000@laposte.net>:
Et à quoi ce serveur va-t-il servir ?
Suivant l'utilité, il y a d'autres moyens de transférer des fichiers,
qui ne posent pas le problème de la double connexion FTP :
- http (ou plutôt https ici)
- rsync (ou unison) over ssh
...et sans doute pas mal d'autres.
FTP a un gros point fort : il est très répandu, donc tu n'as pas à
faire de formation ou envoyer des logiciels.
Dans ton cas, j'imagine que le nombre de personnes à accéder à ta
machine est très réduit (moins d'une dizaine -- au-delà c'est le
bordel), donc une solution moins classique n'est pas gênante.
Bonjour
Merci pour vos réponses. Ce serveur FTP sert principalement à mettre à
ma disposition des fichiers d'install quand je vais chez les clients.
Mais, il me sert aussi (allez, pour 30%) à mettre à disposition des
fichiers pour des clients & fournisseurs (avec répertoire particulier,
mais je leur communique un login & mdp bien particulier).
Donc, il me fallait une solution avec une sécurité correcte (mais les
fichiers ne sont pas trés important), mais qui soit facilement
accessible pour un grand nombres de clients/fournisseurs.
Et à quoi ce serveur va-t-il servir ? Suivant l'utilité, il y a d'autres moyens de transférer des fichiers, qui ne posent pas le problème de la double connexion FTP : - http (ou plutôt https ici) - rsync (ou unison) over ssh ...et sans doute pas mal d'autres.
FTP a un gros point fort : il est très répandu, donc tu n'as pas à faire de formation ou envoyer des logiciels. Dans ton cas, j'imagine que le nombre de personnes à accéder à ta machine est très réduit (moins d'une dizaine -- au-delà c'est le bordel), donc une solution moins classique n'est pas gênante.
Bonjour
Merci pour vos réponses. Ce serveur FTP sert principalement à mettre à ma disposition des fichiers d'install quand je vais chez les clients. Mais, il me sert aussi (allez, pour 30%) à mettre à disposition des fichiers pour des clients & fournisseurs (avec répertoire particulier, mais je leur communique un login & mdp bien particulier). Donc, il me fallait une solution avec une sécurité correcte (mais les fichiers ne sont pas trés important), mais qui soit facilement accessible pour un grand nombres de clients/fournisseurs.
Bien le Bonjour de Corse
Fabien LE LEZ
On 10 Aug 2005 18:12:52 GMT, Corsica :
Merci pour vos réponses. Ce serveur FTP sert principalement à mettre à ma disposition des fichiers d'install quand je vais chez les clients.
Donc, il fonctionne en lecture seule ? Dans ce cas, le protocole HTTP (ou HTTPS) avec mot de passe me paraît le plus adapté.
On 10 Aug 2005 18:12:52 GMT, Corsica <spam.pubb2000@laposte.net>:
Merci pour vos réponses. Ce serveur FTP sert principalement à mettre à
ma disposition des fichiers d'install quand je vais chez les clients.
Donc, il fonctionne en lecture seule ?
Dans ce cas, le protocole HTTP (ou HTTPS) avec mot de passe me paraît
le plus adapté.
Merci pour vos réponses. Ce serveur FTP sert principalement à mettre à ma disposition des fichiers d'install quand je vais chez les clients.
Donc, il fonctionne en lecture seule ? Dans ce cas, le protocole HTTP (ou HTTPS) avec mot de passe me paraît le plus adapté. Bonjour
Il fonctionne en lecture seule pour tout le monde, sauf pour 2 users qui eux, ont le droit d'écriture.
Bien el Bonjour de Corse
Eric Razny
Le Thu, 11 Aug 2005 16:10:27 +0000, Corsica a écrit :
On 10 Aug 2005 18:12:52 GMT, Corsica :
Merci pour vos réponses. Ce serveur FTP sert principalement à mettre à ma disposition des fichiers d'install quand je vais chez les clients.
Donc, il fonctionne en lecture seule ? Dans ce cas, le protocole HTTP (ou HTTPS) avec mot de passe me paraît le plus adapté. Bonjour
Il fonctionne en lecture seule pour tout le monde, sauf pour 2 users qui eux, ont le droit d'écriture.
Tu peux très bien uploader, généralement par POST, un fichier via http. Tu peux même demander à ces utilisateurs d'avoir un certif maison si tu passe par https (qui est très conseillé dans ton cas!).
En plus tu ne sera moins emmerdé pour l'upload car on trouve plus facilement un browser bidon[1] sous la main qu'un bon client ftp :)
Eric.
[1] Du type de ceux qui affichent le contenu html quand le Content-Type: est text/plain ;) )
Le Thu, 11 Aug 2005 16:10:27 +0000, Corsica a écrit :
On 10 Aug 2005 18:12:52 GMT, Corsica <spam.pubb2000@laposte.net>:
Merci pour vos réponses. Ce serveur FTP sert principalement à mettre
à ma disposition des fichiers d'install quand je vais chez les
clients.
Donc, il fonctionne en lecture seule ? Dans ce cas, le protocole HTTP
(ou HTTPS) avec mot de passe me paraît le plus adapté.
Bonjour
Il fonctionne en lecture seule pour tout le monde, sauf pour 2 users qui
eux, ont le droit d'écriture.
Tu peux très bien uploader, généralement par POST, un fichier via http.
Tu peux même demander à ces utilisateurs d'avoir un certif maison si tu
passe par https (qui est très conseillé dans ton cas!).
En plus tu ne sera moins emmerdé pour l'upload car on trouve plus
facilement un browser bidon[1] sous la main qu'un bon client ftp :)
Eric.
[1] Du type de ceux qui affichent le contenu html quand le Content-Type:
est text/plain ;) )
Le Thu, 11 Aug 2005 16:10:27 +0000, Corsica a écrit :
On 10 Aug 2005 18:12:52 GMT, Corsica :
Merci pour vos réponses. Ce serveur FTP sert principalement à mettre à ma disposition des fichiers d'install quand je vais chez les clients.
Donc, il fonctionne en lecture seule ? Dans ce cas, le protocole HTTP (ou HTTPS) avec mot de passe me paraît le plus adapté. Bonjour
Il fonctionne en lecture seule pour tout le monde, sauf pour 2 users qui eux, ont le droit d'écriture.
Tu peux très bien uploader, généralement par POST, un fichier via http. Tu peux même demander à ces utilisateurs d'avoir un certif maison si tu passe par https (qui est très conseillé dans ton cas!).
En plus tu ne sera moins emmerdé pour l'upload car on trouve plus facilement un browser bidon[1] sous la main qu'un bon client ftp :)
Eric.
[1] Du type de ceux qui affichent le contenu html quand le Content-Type: est text/plain ;) )
