probleme de connection sur serveur ftp

Bonjour,
J'ai installé un serveur ftp sur ma machine avec Serv-u 6.2, et j'ai créé une règle dans LnS autorisant le transfert ftp sur les ports 20 et 21 grace à des posts que j'ai trouvé ici.
Cependant lorsque quelqu'un essaie d'accéder à mon serveur depuis l'extérieur, il n'arrive jamais à voir la liste des directories (je le vois pourtant connecté dans servU), ou parfois meme à se connecter.
Quand je désactive LnS plus aucun problème.

 

Qu'indique le journal de Look 'n' Stop ?
Coté client peut être que changer le mode de connecion PASV/No PASV peut aider.

Frédéric

 

le journal indique juste qu'il y a eu connection dans les deux sens sur une adresse aléatoire, elle change à chaque fois....
les clients sont toujours en passive mode...

 

Est-ce que ce sont bien des alertes de packets autorisés et non de paquets bloqués ?
Si finalement il n'y a aucun paquet bloqués indiqués dans le journal, peut être que le problème vient du filtrage logiciel. Plutôt que de désactiver complètement Look 'n' Stop la prochaine fois (pour faire réussir le transfert FTP) essayez de juste désactiver le filtrage logiciel.

Merci,

Frédéric.

 

Bonsoir,

Cherche pas plus loin, il est la le probleme Si les clients demandent du passif (PASV), c'est pour ne pas ouvrir de port sur leur machine : on inverse ainsi les roles et c'est eux qui viennent se connecter sur un port defini par le serveur pour chaque canal de données ouvert => en tant que serveur FTP tu dois ouvrir une plage de ports pour les clients demandant du passif

 

oui je pense que le probleme vient de la, mais quelle plage de ports definir? je cree une nouvelle regle?

 

Je n'ai jamais utilisé Serv-u... j'ai trouvé ce pdf qui semble expliquer la demarche (paragraphes 3 & 4). Il faudra créer une regle qui ouvre la meme plage et effectuer un port range forwarding si tu as un routeur. Pour la largeur de la plage, ca depend du nombre de clients et de l'activité (petits/gros fichiers... nb requetes)!

 

merci c'est bon ça marche, j'ai ouvert les ports 2000 à 2010 dans ser-U, et j'ai créé une nouvelle règle dans lns qui ouvre les memes ports pour cette application. Par contre j'ai remarqué qu'il faut redémarrer pour que les changements soient effectifs..

 

Petite question sur ton serveur ftp:

Moi aussi je me suis monté un serveur ftp. J'ai editer une regle pour editer la plage de port adequat (989 et 990 car c est du ssl). Le probleme, c est qu en faisant le test de firewall de grc.com, je me retrouve avec le port 989 closed et 990 open...

por le 990 c est normal puisqu il attend la connexion... ce qui m embete c est le port 989 closed. J ai testé avec un autre firewall gratuit et je me retrouve avec le 989 stealth...

Alors ma question est:
- Est ceque toi aussi ta plage de port apparait closed
- Sinon comment faire pour la faire devenir stealth..

Merci a toi et à tout ceux qui pourront me repondre!

 

Salut,

C'est normal car, si je ne dis pas de betises : toute regle associé a ton application est active sssi au moins une socket créée par cette derniere est vivante (connexion/ecoute). Comme ton serveur se met en ecoute a son demarrage, toute regle associée est alors active.

 

pas de probleme... c est pour ça que je ne m'affole pas pour le port 990...

Par contre, il n'y a aucune connexion avec un client... alors pourquoi le port 989 est il closed??

Mais surtout ceux qui m'embête par dessus tout, c est qu'un autre firewall arrive à me mettre le port 989 stealth... (tout en laissant mon serveur operationnel evidemment..)

N'y aurait il pas moyen de faire la meme chose avec look'n'stop?

 

La reponse est dans ma precedente reponse

Tu as créé une regle qui ouvre les ports TCP 989 et 990 et tu l'as associé a ton application. Quand ton application demarre, LNS detecte que ton serveur tente de se mettre en ecoute et active ta regle. Resultat, en terme de visibilité depuis l'exterieur :
- ton port TCP 990 est ouvert (ouvert car accessible grace a ta regle et utilisé : ton serveur est en ecoute dessus),
- ton port TCP 889 est fermé (fermé car accessible grace a ta regle mais pas encore utilisé).

De toute facon, un port ouvert est plus dangereux qu'un port fermé

Non, pas a ma connaissance. Mais ca m'interesserait aussi. Frederic?

 

Bon et bien tant pis...

Mais il est dommage qu'un logiciel aussi terrible que look'n'stop ne puisse pas faire comme la concurence ....

En esperant que dans les prochaines versions ceci soit ajouter...

Merci pour les reponses en tout cas... mais si quelqu'un sait comment rendre ce port stealth (ainsi que tous les ports du mode passif d'un serveur d'ailleurs)... je reste à l'écoute!

 

Salut

Lorsqu'un serveur est en opération (n'importe lequel: http, ftp, partie serveur d'un bidule P2P, etc) il est tout à fait normal que le port utilisé pour les connections entrantes ne soit pas furtif (stealth) sinon comment les connections se feraient-elles ?

[Voir première image avec Shareaza sous Gnutella en opération...]

Quand le serveur n'est pas en opération les ports correspondants sont furtifs...

[Voir deuxième image sans le serveur P2P en opération...]

Quand le serveur est en opération et que des ports alloués pour ce serveur ne sont pas utilisés alors ces ports ne sont pas furtifs et s'ils sont sollicités par une autre application que celle prévue par la règle alors le port alloué et non-utilisé répond à la sollicitation par un paquet TCP avec les flags ACK-RST (? ou Syn-Rst ? à vérifier...)
signalant qu'il est fermé (ou "Closed")...

[Voir les première et la troisième images: des ports alloués mais non utilisés...]

La raison pour laquelle ces ports sont indiqués "Closed" c'est soit que comme dans l'exemple des ports sont alloués pour le serveur mais non utilisés.
Dans le cas d'un serveur Ftp acceptant le mode passif c'est inévitable...
tant que le serveur est en opération.

Tu pourrais essayer de placer une règle avant celle de la règle de ton serveur
Ftp pour bloquer les paquets TCP sortants avec les flags ACK-RST pour voir ce que ça donne...
(Expérimental...)

A+

 

sans le serveur P2P en opération...

 

des ports alloués mais non utilisés...
Comme tu le vois dans cet exemple, cette règle pour la partie serveur de Shareaza avec Gnutella prévoit l'utilisation des ports locaux de 6346 à 6349 pour les connexions entrantes... Cependant losr de l'utilisation seul le port 6346 était utilisé (donc pas furtif et c'est normal : ouvert pour les connexions entrantes...) et les autres ports signalés
comme fermés parce qu'alloués mais pas utilisés...

Pour être clair : on ne peut pas avoir à la fois un PC furtif ET un serveur sur ce PC lorsque ce serveur est en opération...

 

Pas concluant... autre chose alors...

Qq1 va finir par trouver... ;-)

Il est tard, je vais roupiller.

A+

 

Merci pour toutes ces precisions... génial

Je teste de suite ta solution.. sinon tant pis... c'est normal!

 

Bah oui normal (avec des images en plus)

De toute facon l'ouverture du port TCP 990 ruine ton stealth-mode Une solution serait de whitelister les adresses des clients (LNS, protowall... ou un VPN)!

 

Salut Bloodscourge

Tout le problème ne vient-il pas du fait qu'il doit utiliser le mode passif ou plutôt permettre aux utilisateurs de son Ftp de le faire? S'il ne donnait accès qu'à des utilisateurs inscrits avec password par ex. il serait peut-être possible de limiter l'accès aux ports 20 et 21 seulement...
Oui ? non ?

Qu'est-ce que tu en pense?

P.S.
Ouais... c'est plus joli avec des images !
Ça donne une apparence géniale à un post

 

En fait je faisais ces suggestions pour que son PC reste furtif malgré son serveur FTP, pas pour remplacer l'authentitification evidemment de rigueur . Pour les ports 20/21, ca depend de ses choix mais dragonbools semble vouloir du FTPS.