J'ai un petit probleme car j'utilise TYPSoft FTP serveur et j'ai ZApro
comme firewall.
Le probleme est que je suis obligé de desactiver ZA parce qu'il refuse
la connection du client.
Pourtant j'ai bien ouvert 20,21 en TCP et UDP.
Quand je donne le lien vers mon serveur j'avoute pourtant bien le :21
a la fin pour obliger la connexion sur le port 21.
Seulement les client d'en face se connecte soit sur 12,68, 74,
198,235,238,241,249,250,253.......Ca se voit car mon serveur m'affin
l'IP du client + 2 chiffre a la fin (port ?) genre 80,xx,xx,xx,xx,port
D'ailleur je viens de me rendre compte a l'instant que c'est 4 chiffre
de plus. Actuelement c'est IP,13,74
Je ne sais pas comment faire.
Pouvez vous m'aider.
merci.
--
90 % des hommes politiques donnent une mauvaise
réputation aux 10 % qui restent.
On 19 Jul 2003 15:08:08 GMT, foo tche bol <cekoidon.?@host.free.fr> wrote:
J'ai un petit probleme car j'utilise TYPSoft FTP serveur et j'ai ZApro comme firewall. Le probleme est que je suis obligé de desactiver ZA parce qu'il refuse la connection du client.
Est-ce que la connexion de contrôle se fait ? Ou le client ne peut pas du tout se connecter ?
Le principe de la connexion FTP : le client ouvre une connexion "principale", dite de contrôle, sur le port 21 du serveur. Une fois cette connexion établie, il peut envoyer login et mot de passe, puis d'autres commandes (CWD par exemple pour changer de répertoire). Quand le client demande (toujours via cette connexion de contrôle) un transfert de fichier, le serveur ouvre une connexion de données vers le port 20 du client. Comme côté serveur, le port peut varier, le serveur FTP doit donc pouvoir ouvrir une connexion sortante via n'importe quel port, vers le port 20 du client. Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui fait que c'est le client qui ouvre une connexion de données vers le serveur, mais je n'ai jamais testé.
Enfin bon, le mieux est encore d'ouvrir une connexion "à la main" (via le FTP en ligne de commande par exemple), pour essayer de voir à quel moment ça coince.
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
On 19 Jul 2003 15:08:08 GMT, foo tche bol <cekoidon.?@host.free.fr>
wrote:
J'ai un petit probleme car j'utilise TYPSoft FTP serveur et j'ai ZApro
comme firewall.
Le probleme est que je suis obligé de desactiver ZA parce qu'il refuse
la connection du client.
Est-ce que la connexion de contrôle se fait ? Ou le client ne peut pas
du tout se connecter ?
Le principe de la connexion FTP : le client ouvre une connexion
"principale", dite de contrôle, sur le port 21 du serveur. Une fois
cette connexion établie, il peut envoyer login et mot de passe, puis
d'autres commandes (CWD par exemple pour changer de répertoire).
Quand le client demande (toujours via cette connexion de contrôle) un
transfert de fichier, le serveur ouvre une connexion de données vers
le port 20 du client. Comme côté serveur, le port peut varier, le
serveur FTP doit donc pouvoir ouvrir une connexion sortante via
n'importe quel port, vers le port 20 du client.
Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui
fait que c'est le client qui ouvre une connexion de données vers le
serveur, mais je n'ai jamais testé.
Enfin bon, le mieux est encore d'ouvrir une connexion "à la main" (via
le FTP en ligne de commande par exemple), pour essayer de voir à quel
moment ça coince.
--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
On 19 Jul 2003 15:08:08 GMT, foo tche bol <cekoidon.?@host.free.fr> wrote:
J'ai un petit probleme car j'utilise TYPSoft FTP serveur et j'ai ZApro comme firewall. Le probleme est que je suis obligé de desactiver ZA parce qu'il refuse la connection du client.
Est-ce que la connexion de contrôle se fait ? Ou le client ne peut pas du tout se connecter ?
Le principe de la connexion FTP : le client ouvre une connexion "principale", dite de contrôle, sur le port 21 du serveur. Une fois cette connexion établie, il peut envoyer login et mot de passe, puis d'autres commandes (CWD par exemple pour changer de répertoire). Quand le client demande (toujours via cette connexion de contrôle) un transfert de fichier, le serveur ouvre une connexion de données vers le port 20 du client. Comme côté serveur, le port peut varier, le serveur FTP doit donc pouvoir ouvrir une connexion sortante via n'importe quel port, vers le port 20 du client. Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui fait que c'est le client qui ouvre une connexion de données vers le serveur, mais je n'ai jamais testé.
Enfin bon, le mieux est encore d'ouvrir une connexion "à la main" (via le FTP en ligne de commande par exemple), pour essayer de voir à quel moment ça coince.
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
Cedric Blancher
Dans sa prose, Fabien LE LEZ nous ecrivait : [...]
Quand le client demande (toujours via cette connexion de contrôle) un transfert de fichier, le serveur ouvre une connexion de données vers le port 20 du client.
Non, en actif, c'est _depuis_ le port 20 de serveur, _vers_ un port non privilégié du client, en général celui immédiatement supérieur à celui utilisé pour le canal de commande.
Comme côté serveur, le port peut varier, le serveur FTP doit donc pouvoir ouvrir une connexion sortante via n'importe quel port, vers le port 20 du client.
C'est le client qui doit être joignable sur n'importe quel port non privilégie, depuis un port 20.
Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui fait que c'est le client qui ouvre une connexion de données vers le serveur, mais je n'ai jamais testé.
En passif, c'est le client qui initie la connexion de données, en utilisant un port non privilégié, vers un port non privilégié du serveur.
En gros, si on veut si on veut faire du FTP tranquille, il faut autoriser les connexions :
TCP sortant >1023 vers 21 pour le canal de données TCP entrant 20 vers >1023 pour le canal de données actif TCP sortant >1023 vers >1023 pour le canal de données passif.
-- FB: Euh, c'est quoi les conférences fidonet ? FK: C'est pour ceux qui préfèrent les chiens aux drosophiles. -+- in: Guide du Cabaliste Usenet - La SPA vaincra ! -+-
Dans sa prose, Fabien LE LEZ nous ecrivait : [...]
Quand le client demande (toujours via cette connexion de contrôle) un
transfert de fichier, le serveur ouvre une connexion de données vers le
port 20 du client.
Non, en actif, c'est _depuis_ le port 20 de serveur, _vers_ un port non
privilégié du client, en général celui immédiatement supérieur à
celui utilisé pour le canal de commande.
Comme côté serveur, le port peut varier, le serveur FTP doit donc
pouvoir ouvrir une connexion sortante via n'importe quel port, vers le
port 20 du client.
C'est le client qui doit être joignable sur n'importe quel port non
privilégie, depuis un port 20.
Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui
fait que c'est le client qui ouvre une connexion de données vers le
serveur, mais je n'ai jamais testé.
En passif, c'est le client qui initie la connexion de données, en
utilisant un port non privilégié, vers un port non privilégié du serveur.
En gros, si on veut si on veut faire du FTP tranquille, il faut autoriser
les connexions :
TCP sortant >1023 vers 21 pour le canal de données
TCP entrant 20 vers >1023 pour le canal de données actif
TCP sortant >1023 vers >1023 pour le canal de données passif.
--
FB: Euh, c'est quoi les conférences fidonet ?
FK: C'est pour ceux qui préfèrent les chiens aux drosophiles.
-+- in: Guide du Cabaliste Usenet - La SPA vaincra ! -+-
Dans sa prose, Fabien LE LEZ nous ecrivait : [...]
Quand le client demande (toujours via cette connexion de contrôle) un transfert de fichier, le serveur ouvre une connexion de données vers le port 20 du client.
Non, en actif, c'est _depuis_ le port 20 de serveur, _vers_ un port non privilégié du client, en général celui immédiatement supérieur à celui utilisé pour le canal de commande.
Comme côté serveur, le port peut varier, le serveur FTP doit donc pouvoir ouvrir une connexion sortante via n'importe quel port, vers le port 20 du client.
C'est le client qui doit être joignable sur n'importe quel port non privilégie, depuis un port 20.
Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui fait que c'est le client qui ouvre une connexion de données vers le serveur, mais je n'ai jamais testé.
En passif, c'est le client qui initie la connexion de données, en utilisant un port non privilégié, vers un port non privilégié du serveur.
En gros, si on veut si on veut faire du FTP tranquille, il faut autoriser les connexions :
TCP sortant >1023 vers 21 pour le canal de données TCP entrant 20 vers >1023 pour le canal de données actif TCP sortant >1023 vers >1023 pour le canal de données passif.
-- FB: Euh, c'est quoi les conférences fidonet ? FK: C'est pour ceux qui préfèrent les chiens aux drosophiles. -+- in: Guide du Cabaliste Usenet - La SPA vaincra ! -+-
foo tche bol
On 19 Jul 2003 15:39:49 GMT, Fabien LE LEZ wrote:
On 19 Jul 2003 15:08:08 GMT, foo tche bol <cekoidon.?@host.free.fr> wrote:
J'ai un petit probleme car j'utilise TYPSoft FTP serveur et j'ai ZApro comme firewall. Le probleme est que je suis obligé de desactiver ZA parce qu'il refuse la connection du client.
Est-ce que la connexion de contrôle se fait ? Ou le client ne peut pas du tout se connecter ? La personne est connecté chez moi, le mot de passe est validez.
Le principe de la connexion FTP : le client ouvre une connexion "principale", dite de contrôle, sur le port 21 du serveur. Ca c'est bon
Une fois cette connexion établie, il peut envoyer login et mot de passe, Ca aussi
puis d'autres commandes (CWD par exemple pour changer de répertoire). Là ca va plus. Il n'a pas acces au repertoire.
Quand le client demande (toujours via cette connexion de contrôle) un transfert de fichier, le serveur ouvre une connexion de données vers le port 20 du client. Comme côté serveur, le port peut varier, le serveur FTP doit donc pouvoir ouvrir une connexion sortante via n'importe quel port, vers le port 20 du client. Ha bon ?
Le FTP c'est pourtant bien le 20 et 21 ? Comment forcer ces port et pas les autres ?
Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui fait que c'est le client qui ouvre une connexion de données vers le serveur, mais je n'ai jamais testé.
Oui mais ca doit etre pareil, non ? il peut se connecté sur n'importe quel port a ce moment là...
Enfin bon, le mieux est encore d'ouvrir une connexion "à la main" (via le FTP en ligne de commande par exemple), pour essayer de voir à quel moment ça coince.
Sans le firewall ca marche. Le probleme vient de lui. Si je veux que ca marche, soit je desactive le firewall soit j'ouvre tous les ports. -- 90 % des hommes politiques donnent une mauvaise réputation aux 10 % qui restent.
On 19 Jul 2003 15:39:49 GMT, Fabien LE LEZ <gramster@gramster.com>
wrote:
On 19 Jul 2003 15:08:08 GMT, foo tche bol <cekoidon.?@host.free.fr>
wrote:
J'ai un petit probleme car j'utilise TYPSoft FTP serveur et j'ai ZApro
comme firewall.
Le probleme est que je suis obligé de desactiver ZA parce qu'il refuse
la connection du client.
Est-ce que la connexion de contrôle se fait ? Ou le client ne peut pas
du tout se connecter ?
La personne est connecté chez moi, le mot de passe est validez.
Le principe de la connexion FTP : le client ouvre une connexion
"principale", dite de contrôle, sur le port 21 du serveur.
Ca c'est bon
Une fois
cette connexion établie, il peut envoyer login et mot de passe,
Ca aussi
puis
d'autres commandes (CWD par exemple pour changer de répertoire).
Là ca va plus. Il n'a pas acces au repertoire.
Quand le client demande (toujours via cette connexion de contrôle) un
transfert de fichier, le serveur ouvre une connexion de données vers
le port 20 du client. Comme côté serveur, le port peut varier, le
serveur FTP doit donc pouvoir ouvrir une connexion sortante via
n'importe quel port, vers le port 20 du client.
Ha bon ?
Le FTP c'est pourtant bien le 20 et 21 ?
Comment forcer ces port et pas les autres ?
Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui
fait que c'est le client qui ouvre une connexion de données vers le
serveur, mais je n'ai jamais testé.
Oui mais ca doit etre pareil, non ? il peut se connecté sur n'importe
quel port a ce moment là...
Enfin bon, le mieux est encore d'ouvrir une connexion "à la main" (via
le FTP en ligne de commande par exemple), pour essayer de voir à quel
moment ça coince.
Sans le firewall ca marche.
Le probleme vient de lui. Si je veux que ca marche, soit je desactive
le firewall soit j'ouvre tous les ports.
--
90 % des hommes politiques donnent une mauvaise
réputation aux 10 % qui restent.
On 19 Jul 2003 15:08:08 GMT, foo tche bol <cekoidon.?@host.free.fr> wrote:
J'ai un petit probleme car j'utilise TYPSoft FTP serveur et j'ai ZApro comme firewall. Le probleme est que je suis obligé de desactiver ZA parce qu'il refuse la connection du client.
Est-ce que la connexion de contrôle se fait ? Ou le client ne peut pas du tout se connecter ? La personne est connecté chez moi, le mot de passe est validez.
Le principe de la connexion FTP : le client ouvre une connexion "principale", dite de contrôle, sur le port 21 du serveur. Ca c'est bon
Une fois cette connexion établie, il peut envoyer login et mot de passe, Ca aussi
puis d'autres commandes (CWD par exemple pour changer de répertoire). Là ca va plus. Il n'a pas acces au repertoire.
Quand le client demande (toujours via cette connexion de contrôle) un transfert de fichier, le serveur ouvre une connexion de données vers le port 20 du client. Comme côté serveur, le port peut varier, le serveur FTP doit donc pouvoir ouvrir une connexion sortante via n'importe quel port, vers le port 20 du client. Ha bon ?
Le FTP c'est pourtant bien le 20 et 21 ? Comment forcer ces port et pas les autres ?
Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui fait que c'est le client qui ouvre une connexion de données vers le serveur, mais je n'ai jamais testé.
Oui mais ca doit etre pareil, non ? il peut se connecté sur n'importe quel port a ce moment là...
Enfin bon, le mieux est encore d'ouvrir une connexion "à la main" (via le FTP en ligne de commande par exemple), pour essayer de voir à quel moment ça coince.
Sans le firewall ca marche. Le probleme vient de lui. Si je veux que ca marche, soit je desactive le firewall soit j'ouvre tous les ports. -- 90 % des hommes politiques donnent une mauvaise réputation aux 10 % qui restent.
Annie D.
Fabien LE LEZ wrote:
Le principe de la connexion FTP : le client ouvre une connexion "principale", dite de contrôle, sur le port 21 du serveur. Une fois cette connexion établie, il peut envoyer login et mot de passe, puis d'autres commandes (CWD par exemple pour changer de répertoire).
OK.
Quand le client demande (toujours via cette connexion de contrôle) un transfert de fichier, le serveur ouvre une connexion de données vers le port 20 du client.
Non. En mode actif, le serveur envoie une demande de connexion à partir de son propre port 20 (privilégié) source vers un port destination (généralement non privilégié puisque le logiciel client n'est pas censé avoir des droits spéciaux) que le client ouvre en écoute et dont il a transmis le numéro au serveur dans la commande PORT.
Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui fait que c'est le client qui ouvre une connexion de données vers le serveur, mais je n'ai jamais testé.
Voilà. Les navigateurs web qui savent faire du FTP utilisent généralement le mode passif car il passe plus facilement à travers les firewalls côté client. Par contre la mise en place d'un firewall côté serveur est plus délicate car le port de la connexion de données à ouvrir est variable.
Fabien LE LEZ wrote:
Le principe de la connexion FTP : le client ouvre une connexion
"principale", dite de contrôle, sur le port 21 du serveur. Une fois
cette connexion établie, il peut envoyer login et mot de passe, puis
d'autres commandes (CWD par exemple pour changer de répertoire).
OK.
Quand le client demande (toujours via cette connexion de contrôle) un
transfert de fichier, le serveur ouvre une connexion de données vers
le port 20 du client.
Non. En mode actif, le serveur envoie une demande de connexion à partir
de son propre port 20 (privilégié) source vers un port destination
(généralement non privilégié puisque le logiciel client n'est pas censé
avoir des droits spéciaux) que le client ouvre en écoute et dont il a
transmis le numéro au serveur dans la commande PORT.
Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui
fait que c'est le client qui ouvre une connexion de données vers le
serveur, mais je n'ai jamais testé.
Voilà. Les navigateurs web qui savent faire du FTP utilisent
généralement le mode passif car il passe plus facilement à travers les
firewalls côté client. Par contre la mise en place d'un firewall côté
serveur est plus délicate car le port de la connexion de données à
ouvrir est variable.
Le principe de la connexion FTP : le client ouvre une connexion "principale", dite de contrôle, sur le port 21 du serveur. Une fois cette connexion établie, il peut envoyer login et mot de passe, puis d'autres commandes (CWD par exemple pour changer de répertoire).
OK.
Quand le client demande (toujours via cette connexion de contrôle) un transfert de fichier, le serveur ouvre une connexion de données vers le port 20 du client.
Non. En mode actif, le serveur envoie une demande de connexion à partir de son propre port 20 (privilégié) source vers un port destination (généralement non privilégié puisque le logiciel client n'est pas censé avoir des droits spéciaux) que le client ouvre en écoute et dont il a transmis le numéro au serveur dans la commande PORT.
Il me semble qu'il existe un autre mode (est-ce le mode passif ?) qui fait que c'est le client qui ouvre une connexion de données vers le serveur, mais je n'ai jamais testé.
Voilà. Les navigateurs web qui savent faire du FTP utilisent généralement le mode passif car il passe plus facilement à travers les firewalls côté client. Par contre la mise en place d'un firewall côté serveur est plus délicate car le port de la connexion de données à ouvrir est variable.
foo tche bol
On 19 Jul 2003 18:20:11 GMT, "Annie D." wrote:
Voilà. Les navigateurs web qui savent faire du FTP utilisent généralement le mode passif car il passe plus facilement à travers les firewalls côté client. Par contre la mise en place d'un firewall côté serveur est plus délicate car le port de la connexion de données à ouvrir est variable.
Pourquoi est elle variable ? N'y a t il pas un moyen de la rendre fixe en l'imposant par le serveur ?
-- 90 % des hommes politiques donnent une mauvaise réputation aux 10 % qui restent.
On 19 Jul 2003 18:20:11 GMT, "Annie D." <annie.demur@free.fr> wrote:
Voilà. Les navigateurs web qui savent faire du FTP utilisent
généralement le mode passif car il passe plus facilement à travers les
firewalls côté client. Par contre la mise en place d'un firewall côté
serveur est plus délicate car le port de la connexion de données à
ouvrir est variable.
Pourquoi est elle variable ?
N'y a t il pas un moyen de la rendre fixe en l'imposant par le serveur
?
--
90 % des hommes politiques donnent une mauvaise
réputation aux 10 % qui restent.
Voilà. Les navigateurs web qui savent faire du FTP utilisent généralement le mode passif car il passe plus facilement à travers les firewalls côté client. Par contre la mise en place d'un firewall côté serveur est plus délicate car le port de la connexion de données à ouvrir est variable.
Pourquoi est elle variable ? N'y a t il pas un moyen de la rendre fixe en l'imposant par le serveur ?
-- 90 % des hommes politiques donnent une mauvaise réputation aux 10 % qui restent.
Eric Razny
"foo tche bol" <cekoidon.?@host.free.fr> a écrit dans le message de news:
On 19 Jul 2003 18:20:11 GMT, "Annie D." wrote:
Voilà. Les navigateurs web qui savent faire du FTP utilisent généralement le mode passif car il passe plus facilement à travers les firewalls côté client. Par contre la mise en place d'un firewall côté serveur est plus délicate car le port de la connexion de données à ouvrir est variable.
Pourquoi est elle variable ? N'y a t il pas un moyen de la rendre fixe en l'imposant par le serveur ?
http://www.faqs.org/rfcs/rfc959.html
Eric
"foo tche bol" <cekoidon.?@host.free.fr> a écrit dans le message de
news:a2ejhvgq9eamnlsj0485msnpa9pm1s9ulb@4ax.com...
On 19 Jul 2003 18:20:11 GMT, "Annie D." <annie.demur@free.fr> wrote:
Voilà. Les navigateurs web qui savent faire du FTP utilisent
généralement le mode passif car il passe plus facilement à travers les
firewalls côté client. Par contre la mise en place d'un firewall côté
serveur est plus délicate car le port de la connexion de données à
ouvrir est variable.
Pourquoi est elle variable ?
N'y a t il pas un moyen de la rendre fixe en l'imposant par le serveur
?
"foo tche bol" <cekoidon.?@host.free.fr> a écrit dans le message de news:
On 19 Jul 2003 18:20:11 GMT, "Annie D." wrote:
Voilà. Les navigateurs web qui savent faire du FTP utilisent généralement le mode passif car il passe plus facilement à travers les firewalls côté client. Par contre la mise en place d'un firewall côté serveur est plus délicate car le port de la connexion de données à ouvrir est variable.
Pourquoi est elle variable ? N'y a t il pas un moyen de la rendre fixe en l'imposant par le serveur ?
http://www.faqs.org/rfcs/rfc959.html
Eric
Soon
"foo tche bol" <cekoidon.?@host.free.fr> a écrit dans le message de news:
On 20 Jul 2003 16:55:23 GMT, "Eric Razny" wrote:
Pourquoi est elle variable ? N'y a t il pas un moyen de la rendre fixe en l'imposant par le serveur ?
http://www.faqs.org/rfcs/rfc959.html
Eric
ARRRGGGG en angliche. Bon ben je lis et je reviens dans six month. See you son
Google.fr est ton ami !
http://abcdrfc.free.fr/rfc-vf/rfc959.html
"foo tche bol" <cekoidon.?@host.free.fr> a écrit dans le message de news:
jntlhv06dnf71gn7p28lu1742kbsc862kk@4ax.com...
On 20 Jul 2003 16:55:23 GMT, "Eric Razny" <trash2@razny.net> wrote:
Pourquoi est elle variable ?
N'y a t il pas un moyen de la rendre fixe en l'imposant par le serveur
?
http://www.faqs.org/rfcs/rfc959.html
Eric
ARRRGGGG en angliche.
Bon ben je lis et je reviens dans six month.
See you son
"foo tche bol" <cekoidon.?@host.free.fr> a écrit dans le message de news:
On 20 Jul 2003 16:55:23 GMT, "Eric Razny" wrote:
Pourquoi est elle variable ? N'y a t il pas un moyen de la rendre fixe en l'imposant par le serveur ?
http://www.faqs.org/rfcs/rfc959.html
Eric
ARRRGGGG en angliche. Bon ben je lis et je reviens dans six month. See you son
Google.fr est ton ami !
http://abcdrfc.free.fr/rfc-vf/rfc959.html
foo tche bol
On 21 Jul 2003 23:37:06 GMT, foo tche bol <cekoidon.?@host.free.fr> wrote:
Je suis passé en mode passif et ca marche. C'est clair qu'en francais ca va plus vite.
Ben non en fait ca marche pas. Ca marche qu'avec 127.0.0.1 et pas depuis l'exterieur.
-- - Faire une reinstall sur une install, c'est comme rajouter de l'huile dans un moteur sans pour autant en faire la vidange. - Hello, je suis un Virus de signature, veuillez à bien vouloir copier ma signature à la place de la votre.
On 21 Jul 2003 23:37:06 GMT, foo tche bol <cekoidon.?@host.free.fr>
wrote:
Je suis passé en mode passif et ca marche.
C'est clair qu'en francais ca va plus vite.
Ben non en fait ca marche pas.
Ca marche qu'avec 127.0.0.1 et pas depuis l'exterieur.
--
- Faire une reinstall sur une install, c'est comme rajouter de l'huile dans un moteur sans pour autant en faire la vidange.
- Hello, je suis un Virus de signature, veuillez à bien vouloir copier ma signature à la place de la votre.
On 21 Jul 2003 23:37:06 GMT, foo tche bol <cekoidon.?@host.free.fr> wrote:
Je suis passé en mode passif et ca marche. C'est clair qu'en francais ca va plus vite.
Ben non en fait ca marche pas. Ca marche qu'avec 127.0.0.1 et pas depuis l'exterieur.
-- - Faire une reinstall sur une install, c'est comme rajouter de l'huile dans un moteur sans pour autant en faire la vidange. - Hello, je suis un Virus de signature, veuillez à bien vouloir copier ma signature à la place de la votre.
Laurent
Par contre la mise en place d'un firewall côté serveur est plus délicate car le port de la connexion de données à ouvrir est variable. Euh...y'a pas beaucoup de firewalls dignes de ce nom qui ne sont pas
capables de gérer le protocole FTP que ce soit pour laisser "sortir" les flux d'un client vers un serveur à l'exterieur ou pour laisser "entrer" les flux des clients vers un serveur FTP (sur une DMZ par exemple) et ce, quelquesoit le mode (passif ou actif).
En revanche, ça peut être bcp plus rigolo lorsque le serveur FTP n'écoute pas un port TCP standard pour l'accueil des connexions pour le canal de commandes. On trouve des firewalls qui ne savent plus gérer le FTP dans ce cas là...on trouve des firewalls qui savent le gérer mais qui dans le cas du mode actif s'attendent inconditionnellement à ce que le port source côté serveur pour le canal DATA soit le port (CMD - 1) sinon ça fonctionne pas (pourtant je crois que rien ne l'impose dans la RFC et le firewall devrait se contenter de connaitre l'IP du serveur et le port du client FTP fourni via la commande PORT...mais bon c'ets pas plus mal pour la sécurité)
Laurent
Par contre la mise en place d'un firewall côté
serveur est plus délicate car le port de la connexion de données à
ouvrir est variable.
Euh...y'a pas beaucoup de firewalls dignes de ce nom qui ne sont pas
capables de gérer le protocole FTP que ce soit pour laisser "sortir" les
flux d'un client vers un serveur à l'exterieur ou pour laisser "entrer" les
flux des clients vers un serveur FTP (sur une DMZ par exemple) et ce,
quelquesoit le mode (passif ou actif).
En revanche, ça peut être bcp plus rigolo lorsque le serveur FTP n'écoute
pas un port TCP standard pour l'accueil des connexions pour le canal de
commandes. On trouve des firewalls qui ne savent plus gérer le FTP dans ce
cas là...on trouve des firewalls qui savent le gérer mais qui dans le cas du
mode actif s'attendent inconditionnellement à ce que le port source côté
serveur pour le canal DATA soit le port (CMD - 1) sinon ça fonctionne pas
(pourtant je crois que rien ne l'impose dans la RFC et le firewall devrait
se contenter de connaitre l'IP du serveur et le port du client FTP fourni
via la commande PORT...mais bon c'ets pas plus mal pour la sécurité)
Par contre la mise en place d'un firewall côté serveur est plus délicate car le port de la connexion de données à ouvrir est variable. Euh...y'a pas beaucoup de firewalls dignes de ce nom qui ne sont pas
capables de gérer le protocole FTP que ce soit pour laisser "sortir" les flux d'un client vers un serveur à l'exterieur ou pour laisser "entrer" les flux des clients vers un serveur FTP (sur une DMZ par exemple) et ce, quelquesoit le mode (passif ou actif).
En revanche, ça peut être bcp plus rigolo lorsque le serveur FTP n'écoute pas un port TCP standard pour l'accueil des connexions pour le canal de commandes. On trouve des firewalls qui ne savent plus gérer le FTP dans ce cas là...on trouve des firewalls qui savent le gérer mais qui dans le cas du mode actif s'attendent inconditionnellement à ce que le port source côté serveur pour le canal DATA soit le port (CMD - 1) sinon ça fonctionne pas (pourtant je crois que rien ne l'impose dans la RFC et le firewall devrait se contenter de connaitre l'IP du serveur et le port du client FTP fourni via la commande PORT...mais bon c'ets pas plus mal pour la sécurité)
Laurent
Cedric Blancher
Dans sa prose, Laurent nous ecrivait :
on trouve des firewalls qui savent le gérer mais qui dans le cas du mode actif s'attendent inconditionnellement à ce que le port source côté serveur pour le canal DATA soit le port (CMD - 1) sinon ça fonctionne pas (pourtant je crois que rien ne l'impose dans la RFC
RFC 959 : File Transfer Protocol :
[...] 5.2. CONNECTIONS [...] The server protocol interpreter shall "listen" on Port L. [...] The user-DTP must "listen" on the specified data port; this may be the default user port (U) or a port specified in the PORT command. The server shall initiate the data connection from his own default data port (L-1) using the specified user data port. The direction of the transfer and the port used will be determined by the FTP service command. [...]
La RFC demande qu'on utilise CMD-1 pour le port initiateur de la connexion de données en actif.
et le firewall devrait se contenter de connaitre l'IP du serveur et le port du client FTP fourni via la commande PORT...mais bon c'ets pas plus mal pour la sécurité)
Le firewall, il suit la RFC. Si tu utilises un client qui n'est pas RFC compliant, change de client.
En outre, on ne peut pas connaître le port source de la connexion de commande en actif dans la mesure où celui-ci n'est pas négocié. C'est très dommageable pour le soucis de restriction maximum qui motive l'utilisation d'un filtrage à états. On se réfère donc à la RFC, et ça nous permet de restreindre l'autorisation contextuelle à une seule et unique connexion pour le flux de données actif, et non un jeu de possibilités.
On remarquera qu'on a un problème de ce type avec le helper IRC qui ne connait ni l'IP de la partie distante, ni l'ensemble des ports, lorsqu'une connexion DCC doit être mise en place. Et là, la RFC ne nous aide pas.
--
AMHA évidemment. Aaaaaah, bon! Tout va bien, il a dit AMHA!!!! :o)
Signature : Emmanuel (GS est un gros con, AMHA) -+- EF in Guide du Fmblien Assassin : "Faut rester poli AMHA" -+-
Dans sa prose, Laurent nous ecrivait :
on trouve des firewalls qui savent le gérer mais qui dans le cas du
mode actif s'attendent inconditionnellement à ce que le port source
côté serveur pour le canal DATA soit le port (CMD - 1) sinon ça
fonctionne pas (pourtant je crois que rien ne l'impose dans la RFC
RFC 959 : File Transfer Protocol :
[...]
5.2. CONNECTIONS
[...]
The server protocol interpreter shall "listen" on Port L.
[...]
The user-DTP must "listen" on the specified data port; this may be
the default user port (U) or a port specified in the PORT command.
The server shall initiate the data connection from his own default
data port (L-1) using the specified user data port. The direction
of the transfer and the port used will be determined by the FTP
service command.
[...]
La RFC demande qu'on utilise CMD-1 pour le port initiateur de la connexion
de données en actif.
et le firewall devrait se contenter de connaitre l'IP du serveur et le
port du client FTP fourni via la commande PORT...mais bon c'ets pas plus
mal pour la sécurité)
Le firewall, il suit la RFC. Si tu utilises un client qui n'est pas RFC
compliant, change de client.
En outre, on ne peut pas connaître le port source de la connexion de
commande en actif dans la mesure où celui-ci n'est pas négocié. C'est très
dommageable pour le soucis de restriction maximum qui motive l'utilisation
d'un filtrage à états. On se réfère donc à la RFC, et ça nous permet de
restreindre l'autorisation contextuelle à une seule et unique connexion
pour le flux de données actif, et non un jeu de possibilités.
On remarquera qu'on a un problème de ce type avec le helper IRC qui ne
connait ni l'IP de la partie distante, ni l'ensemble des ports, lorsqu'une
connexion DCC doit être mise en place. Et là, la RFC ne nous aide pas.
--
AMHA évidemment.
Aaaaaah, bon! Tout va bien, il a dit AMHA!!!! :o)
Signature : Emmanuel (GS est un gros con, AMHA)
-+- EF in Guide du Fmblien Assassin : "Faut rester poli AMHA" -+-
on trouve des firewalls qui savent le gérer mais qui dans le cas du mode actif s'attendent inconditionnellement à ce que le port source côté serveur pour le canal DATA soit le port (CMD - 1) sinon ça fonctionne pas (pourtant je crois que rien ne l'impose dans la RFC
RFC 959 : File Transfer Protocol :
[...] 5.2. CONNECTIONS [...] The server protocol interpreter shall "listen" on Port L. [...] The user-DTP must "listen" on the specified data port; this may be the default user port (U) or a port specified in the PORT command. The server shall initiate the data connection from his own default data port (L-1) using the specified user data port. The direction of the transfer and the port used will be determined by the FTP service command. [...]
La RFC demande qu'on utilise CMD-1 pour le port initiateur de la connexion de données en actif.
et le firewall devrait se contenter de connaitre l'IP du serveur et le port du client FTP fourni via la commande PORT...mais bon c'ets pas plus mal pour la sécurité)
Le firewall, il suit la RFC. Si tu utilises un client qui n'est pas RFC compliant, change de client.
En outre, on ne peut pas connaître le port source de la connexion de commande en actif dans la mesure où celui-ci n'est pas négocié. C'est très dommageable pour le soucis de restriction maximum qui motive l'utilisation d'un filtrage à états. On se réfère donc à la RFC, et ça nous permet de restreindre l'autorisation contextuelle à une seule et unique connexion pour le flux de données actif, et non un jeu de possibilités.
On remarquera qu'on a un problème de ce type avec le helper IRC qui ne connait ni l'IP de la partie distante, ni l'ensemble des ports, lorsqu'une connexion DCC doit être mise en place. Et là, la RFC ne nous aide pas.
--
AMHA évidemment. Aaaaaah, bon! Tout va bien, il a dit AMHA!!!! :o)
Signature : Emmanuel (GS est un gros con, AMHA) -+- EF in Guide du Fmblien Assassin : "Faut rester poli AMHA" -+-
